Repository Properties for C4 Diagramming
C4 Diagrams in Nodinite reuse existing Repository entities — no new top-level entities are required. However, a small set of new properties on Systems, Services, Domains, and Integrations must or should be set to get accurate C4 notation and meaningful diagrams.
This page is the complete reference for all C4-related properties, their values, whether they are required or optional, and what happens when they are not set.
System Properties
Systems in the Repository are used as actors in C4 diagrams — they appear above and below the Domain boundary stack as Persons, Internal Systems, or External Systems.
C4Type (required for C4 actor inclusion)
Controls how a System is rendered in C4 diagrams and what Mermaid syntax is emitted.
| Value | Meaning | Mermaid emitted | Canvas colour | Position hint |
|---|---|---|---|---|
None (default) |
System not intended for C4 diagrams | (not emitted) | — | — |
Person |
An internal human user or role | Person(alias, "Name", "Role") |
Blue | Above boundaries (default) |
PersonExt |
An external human user or role | Person_Ext(alias, "Name", "Role") |
Grey | Above boundaries (default) |
InternalSystem |
An internal software system you own | System(alias, "Name", "Desc") |
Blue | Above boundaries (default) |
ExternalSystem |
Third-party, SaaS, or partner system | System_Ext(alias, "Name", "Desc") |
Grey | Below boundaries (default) |
SystemDb |
An internal system with a database shape | SystemDb(alias, "Name", "Desc") |
Blue | Above boundaries (default) |
SystemDbExt |
An external system with a database shape | SystemDb_Ext(alias, "Name", "Desc") |
Grey | Below boundaries (default) |
SystemQueue |
An internal system with a queue shape | SystemQueue(alias, "Name", "Desc") |
Blue | Above boundaries (default) |
SystemQueueExt |
An external system with a queue shape | SystemQueue_Ext(alias, "Name", "Desc") |
Grey | Below boundaries (default) |
Blue vs grey is determined by whether the variant is internal or external — this is standard C4 model convention and applied automatically.
Where to set it: Repository → Systems → edit a System → C4 tab → C4 Type field.
If not set (None): The System is not presented as a suggested match during the import wizard and does not appear in the Related Diagrams panel entity search. Systems with C4Type = None remain fully functional in all other Repository features (BPM, Landscape, etc.).
C4PersonRole (optional — Person types only)
A short subtitle describing the role of a Person actor. Displayed beneath the person's name on the canvas and emitted as the third parameter in Person(alias, "Name", "Role").
| Example values | Use case |
|---|---|
"Customer" |
External individual purchasing goods/services |
"Administrator" |
IT admin managing the platform |
"Finance Analyst" |
Business user accessing finance reports |
"Partner" |
External organization or EDI trading partner |
If not set: An empty string is used in the Mermaid output. The Person node still renders correctly.
C4PositionHint (optional)
A default placement guidance for the actor when dropped onto the canvas. The designer uses this hint to pre-select the above-boundary or below-boundary actor zone.
| Value | Meaning |
|---|---|
None (default) |
No placement preference — designer places based on C4Type defaults |
Top |
Place above the boundary stack (Persons and InternalSystems usually go here) |
Bottom |
Place below the boundary stack (ExternalSystems usually go here) |
If not set: The designer applies the default placement based on C4Type:
PersonandInternalSystemdefault to TopExternalSystemdefaults to Bottom
Boundaries in Architecture Diagrams
Boundaries in C4 diagrams are resolved during the import wizard — not configured in a separate designer. When you import Mermaid markup containing Boundary(...), System_Boundary(...), Enterprise_Boundary(...), Container_Boundary(...), or Deployment_Node(...) blocks, the wizard presents each one and asks whether to link it to an existing Domain in your Repository.
| Wizard option | Result |
|---|---|
| Link to existing Domain | Boundary is bound to that Domain — the boundary label uses the Domain name, and the Domain appears in the Integration Landscape as a connected node |
| Keep as label-only boundary | Boundary uses the text label from the Mermaid markup — no Repository entity is linked. Useful for external zones, cloud regions, or partner org boundaries |
The boundary type (Container_Boundary, System_Boundary, Enterprise_Boundary, Boundary, Deployment_Node) is detected automatically from the Mermaid macro in the source and stored per boundary element. It does not need to be set manually.
Boundary configuration is per-diagram. Linking or not linking a boundary to a Domain in one diagram does NOT affect the Domain's appearance in the BPM designer or any other C4 diagram.
Service Properties
Services in the Repository are used as containers inside Domain boundaries — the applications, APIs, databases, and message buses in a C4 Container diagram.
C4ContainerType (required for accurate notation)
Classifies the Service as a specific type of C4 Container. Drives the Font Awesome icon shown on the canvas node and the correct C4 semantic label in the Mermaid output.
| Value | C4 Container meaning | Canvas icon | Mermaid emitted |
|---|---|---|---|
None (default, 0) |
Generic container — unspecified type | Container(alias, "Name", "tech", "desc") |
|
WebApp (1) |
Web application | Container(alias, "Name", "tech", "desc") |
|
MobileApp (2) |
Mobile application (iOS/Android) | Container(alias, "Name", "tech", "desc") |
|
API (3) |
RESTful web API, HTTP endpoint, or gRPC service | Container(alias, "Name", "tech", "desc") |
|
Database (4) |
Relational, document, or other datastore | ContainerDb(alias, "Name", "tech", "desc") |
|
MessageBus (5) |
Message queue, event bus, or broker | ContainerQueue(alias, "Name", "tech", "desc") |
|
Microservice (6) |
Microservice | Container(alias, "Name", "tech", "desc") |
|
Function (7) |
Serverless function or scheduled job | Container(alias, "Name", "tech", "desc") |
|
EventStream (8) |
Event stream (Kafka, Event Hub, etc.) | ContainerQueue(alias, "Name", "tech", "desc") |
|
FileStore (9) |
File store or blob storage | Container(alias, "Name", "tech", "desc") |
|
SinglePageApp (10) |
Single-page application or progressive web app | Container(alias, "Name", "tech", "desc") |
|
Queue (11) |
Standalone message queue (point-to-point, decoupled from a bus) | ContainerQueue(alias, "Name", "tech", "desc") |
|
Cache (12) |
Cache or in-memory data store (Redis, Memcached, etc.) | ContainerDb(alias, "Name", "tech", "desc") |
Where to set it: Repository → Services → edit a Service → C4 tab → C4 Container Type field.
If not set (None): The Service renders as a generic rectangle with the icon. All other C4 diagram functionality works normally — only the visual fidelity and Mermaid semantic are affected.
C4ContainerType vs Component Type: These are two independent concerns.
C4ContainerTypeis a structural classification — it controls the Mermaid DSL shape (Container,ContainerDb,ContainerQueue) and is used by the import matching engine. The Component Type (set separately in the icon picker on the Service edit page and the designer Node Inspector) is a visual classification — it controls the icon shown in Repository lists, cards, and diagram canvas tiles. Both should be set for Services that appear in C4 diagrams. A Service should haveC4ContainerType = Databaseto get theContainerDb()cylinder shape in Mermaid and a matching "Database" Component Type to get the cylinder icon on the canvas.
C4Technology (recommended — required for meaningful Mermaid output)
A free-text string describing the technology stack or platform of this Service. This becomes the $techn (technology) parameter in the Mermaid Container(...) block and appears as a small subtitle beneath the service name on the canvas.
| Example values | What they document |
|---|---|
"ASP.NET Core 9" |
The web API framework |
"PostgreSQL 16" |
The database product and version |
"Azure Service Bus" |
The message bus platform |
"BizTalk Server 2020" |
Legacy on-premise integration platform |
"Node.js / Express" |
Microservice runtime |
"Azure Logic Apps" |
Cloud-native workflow service |
Where to set it: Repository → Services → edit a Service → C4 tab → C4 Technology field.
If not set: An empty string is emitted for the $techn parameter. The diagram renders, but stakeholders lose the technology context that makes C4 Container diagrams valuable.
Service Properties — Shared with BPM
The following properties exist on Services for BPM purposes but are reused by C4 Diagrams:
ArtifactRenaming (optional — shared with BPM Designer)
Overrides the display name of the Service on the canvas without changing the name in the Repository. The renamed label is also used in the Mermaid output (as the node's display name) and in any export.
| Without ArtifactRenaming | With ArtifactRenaming |
|---|---|
Canvas shows: INT1337-OutboundOrderService |
Canvas shows: Outbound Orders |
Mermaid: Container(svc_42, "INT1337-OutboundOrderService", ...) |
Mermaid: Container(svc_42, "Outbound Orders", ...) |
This is the same rename capability used in the BPM Designer and stored in the same column.
Domain Properties
Domains in the Repository are used as boundaries in C4 diagrams — the boundary groups that envelope Services. When a new boundary is created for a Domain (either during import or by manually resolving a boundary in the designer), the boundary pre-populates its type and label from the Domain's default values. Setting these defaults ensures every diagram that includes this Domain produces consistent Mermaid output without per-diagram manual correction.
DefaultBoundaryType (recommended — for consistent boundary rendering)
Controls the C4 boundary macro used when a new diagram boundary is created for this Domain.
| Value | Mermaid emitted | Typical use |
|---|---|---|
NULL (not set) |
Boundary created without a seeded type — designer applies its own default | Use when the boundary type varies per diagram or has not been decided yet |
ContainerBoundary (4) |
Container_Boundary(...) |
L2 Container diagrams — a system's container boundary |
SystemBoundary (2) |
System_Boundary(...) |
L1 Context diagrams — a single system's boundary |
EnterpriseBoundary (3) |
Enterprise_Boundary(...) |
L1 Context diagrams — the outermost organisation wrapper |
Boundary (1) |
Boundary(...) |
Generic grouping with a custom type hint |
DeploymentNode (5) |
Deployment_Node(...) |
Deployment diagrams — cloud regions, VNets, on-premises zones |
Where to set it: Repository → Domains → edit a Domain → C4 Properties tab → Default Boundary Type field.
If not set (NULL): The boundary is created without a pre-seeded type. Setting DefaultBoundaryType is recommended for any Domain that appears in multiple C4 diagrams.
Seeding is one-way and one-time. When a boundary is first created for a Domain, it reads
DefaultBoundaryTypeandDefaultTypeLabelfrom the Domain record. Once created, the boundary'sBoundaryTypeand description are independent — editing Domain defaults does not update existing boundaries.
DefaultTypeLabel (optional — for the C4 type hint label)
A short string describing the infrastructure or grouping type. This is the [Azure Region] text visible beneath the boundary name on the canvas and emitted as the third argument of Boundary(...) or Deployment_Node(...).
| Example values | When to use |
|---|---|
"Azure Region" |
Azure geography grouping |
"On-Premises" |
Customer data centre |
"VNet" |
Azure Virtual Network |
"Kubernetes Cluster" |
Container orchestration boundary |
"DMZ" |
Network security zone |
Where to set it: Repository → Domains → edit a Domain → C4 Properties tab → Default Type Label field.
If not set: No type label is emitted. The boundary still renders; the type-hint string simply does not appear.
Integration Properties
Integrations in the Repository appear in L3 Component diagrams as component nodes — the internal building blocks inside a Service. They map to the Component(...), ComponentDb(...), and ComponentQueue(...) C4 macros. Setting C4ComponentKind and C4Technology ensures newly created Integration nodes use the correct Mermaid shape and carry a meaningful technology label.
C4ComponentKind (recommended — for accurate L3 notation)
Classifies the Integration as a specific C4 Component shape. Controls the Mermaid macro emitted in the output.
| Value | Mermaid emitted | Typical use |
|---|---|---|
NULL (not set) |
Component(...) — generic component rectangle |
Use when the shape is not relevant or has not been decided yet |
Component |
Component(...) |
Standard logical component — business logic, orchestration |
ComponentDb |
ComponentDb(...) |
Data-access component — repository pattern, datastore adapter |
ComponentQueue |
ComponentQueue(...) |
Message consumer or producer component |
Where to set it: Repository → Integrations → edit an Integration → C4 Properties tab → C4 Component Kind field.
If not set: The Integration renders as a generic Component(...) rectangle.
C4Technology (recommended — for meaningful component output)
A free-text string describing the technology or framework of this Integration component. Emitted as the $techn parameter in the Component(...) block and displayed as a small subtitle beneath the component name on the canvas.
| Example values | What they document |
|---|---|
"BizTalk Orchestration" |
BizTalk orchestration component |
"Azure Logic App" |
Cloud-native integration workflow |
"C# / NServiceBus" |
.NET messaging consumer |
"XSLT Transform" |
Schema mapping / transformation step |
Where to set it: Repository → Integrations → edit an Integration → C4 Properties tab → C4 Technology field.
If not set: An empty string is emitted for $techn. The component node still renders correctly.
Implicit vs Explicit Properties
Some properties are set explicitly by an administrator before designing a C4 diagram. Others are applied implicitly by the designer during operation.
| Property | Set by | Required before diagramming? |
|---|---|---|
Systems.C4Type |
Administrator / data steward | Yes — Systems without a C4Type are not suggested during import |
Systems.C4PersonRole |
Administrator / data steward | No — defaults to empty string |
Systems.C4PositionHint |
Administrator / data steward | No — defaults based on C4Type |
Services.C4ContainerType |
Administrator / data steward | Recommended — defaults to generic Container; drives correct Mermaid shape and import suggestions |
Services.C4Technology |
Administrator / data steward | Recommended — defaults to empty string |
Services.ArtifactRenaming |
Administrator / data steward | No — optional display name override |
Domains.DefaultBoundaryType |
Administrator / data steward | Recommended — seeds C4DiagramBoundaries.BoundaryType when a Domain boundary is first created |
Domains.DefaultTypeLabel |
Administrator / data steward | No — optional type-hint label (e.g., "Azure Region") seeded into new boundaries |
Integrations.C4ComponentKind |
Administrator / data steward | Recommended — seeds the component shape into new L3 component nodes |
Integrations.C4Technology |
Administrator / data steward | Recommended — seeds the technology label into new L3 component nodes |
C4DiagramNodes.RepositoryEntityType |
Import wizard | Set automatically — controls whether the node binds to a Service, System, or Integration |
C4DiagramNodes.RepositoryEntityId |
Import wizard | Set automatically — the matched entity's ID |
C4DiagramBoundaries.DomainId |
Import wizard | Optional — null if boundary is label-only |
C4DiagramBoundaries.BoundaryType |
Import wizard / seeded from Domain | Detected from Mermaid macro in source, or seeded from Domains.DefaultBoundaryType if the Domain has a default set |
C4DiagramLinks.Label, Protocol |
Import wizard | From Rel(...) parameters in Mermaid source — editable after import |
C4DiagramLinks.IsBidirectional |
Import wizard | From BiRel(...) in Mermaid source — when enabled emits BiRel(...) instead of Rel(...) |
Preparing Your Repository for C4 Diagramming
To get the best results from C4 Diagrams, follow this preparation checklist:
Systems Checklist
- Every System that represents an internal human user or role has
C4Type = Person - Every System that represents an external human user or role has
C4Type = PersonExt - Every System that represents an internal platform has
C4Type = InternalSystem - Every System that represents an external partner, SaaS, or third-party has
C4Type = ExternalSystem - Database-shaped systems use
SystemDb(internal) orSystemDbExt(external) - Queue-shaped systems use
SystemQueue(internal) orSystemQueueExt(external) - Systems not intended for architectural diagrams remain as
C4Type = None - Person-type Systems have a meaningful
C4PersonRolevalue
Services Checklist
- Every Service has a
C4ContainerTypeset to its correct architectural role - Every Service has a
C4Technologyvalue (e.g., framework, database product, or platform name) - Services with long internal codes use
ArtifactRenamingfor business-friendly display names
Domains Checklist
- Domains that appear in C4 diagrams have
DefaultBoundaryTypeset to their most common boundary type - Domains used as Deployment Nodes or generic groupings have a
DefaultTypeLabelset (e.g.,"Azure Region","VNet") - Domains whose boundary type intentionally varies per diagram may leave
DefaultBoundaryTypeasNULLand configure each boundary individually in the designer
Integrations Checklist
- Every Integration that appears in L3 Component diagrams has
C4ComponentKindset to its correct component shape - Every Integration participating in L3 diagrams has a
C4Technologyvalue describing its framework or platform
Frequently Asked Questions
Do these properties affect BPM or other Repository features?
C4Type and C4ContainerType are new columns added to Systems and Services respectively. They are only used by C4 Diagrams and have no effect on BPM, Log Views, Monitor Views, or the Integration Landscape. ArtifactRenaming already existed for BPM and is shared.
Can I set C4 properties via the Web API?
Yes. All properties on System and Service entities are accessible via the Nodinite Web API. You can bulk-update C4Type and C4ContainerType across your entire Repository using a script, which is recommended for large environments. See the Web API documentation for endpoint details.
What happens to the Mermaid output if C4Technology is blank?
The Container(...) block is emitted with an empty string for the $techn parameter. The diagram renders correctly; the technology label simply does not appear on the Mermaid-rendered node. For maximum architectural clarity, setting C4Technology is strongly recommended.
Can I change C4Type or C4ContainerType for an entity already placed in a diagram?
Yes. Because these are global Repository properties, changing them updates all diagrams that include that entity immediately. The canvas and Mermaid output reflect the new value on next load.
Does changing a Domain's DefaultBoundaryType update boundaries in existing diagrams?
No. DefaultBoundaryType and DefaultTypeLabel are seeded once when a boundary is first created in a diagram. After that, the boundary's own BoundaryType and description are stored independently of the Domain record. Changing Domain defaults does not retroactively affect any existing diagram. To update an existing boundary's type, edit it directly in the designer's boundary properties panel.
Can I set Domain and Integration C4 properties via the Web API?
Yes. All properties on Domain and Integration entities are available through the Nodinite Web API. This enables bulk-setting of DefaultBoundaryType and DefaultTypeLabel across large Repository environments. See the Web API documentation for endpoint details.