TECH MONDAY: The C4 Model in Dynamics 365 and the Power Platform – Four Levels of Architecture

Architecture documentation should illustrate both the system's place within the organization and the details of its design. The C4 model organizes this information using four levels of abstraction.

In Dynamics 365 Customer Engagement and Power Platform projects, you can use this approach to describe systems and integrations, Dataverse solutions, Power Apps applications, microservices, custom APIs, workflows, and code.

Four Perspectives on the C4 Model

The model developed by Simon Brown presents the architecture hierarchically—from the system's overall environment down to the technologies used in its code.

The name "C4" refers to four levels:

• C1 – context,
• C2 – containers,
• C3 – components,
• C4 – code.

Each subsequent level addresses different questions and presents the solution in greater detail. This makes it easier to discuss architecture with both technical experts and people without technical knowledge.

Using C4 in Dynamics 365 and Power Platform Projects

Microsoft solution implementations often involve multiple applications, services, and integrations. The C4 model allows you to assign these elements to the appropriate level of documentation.

The general context illustrates the system's business role and its environment. The subsequent layers depict the components that make up the solution, the components responsible for specific functions, and the code used.

This mapping allows the model to be applied to projects that use low-code and no-code tools as well.

C1 – System Context and Integrations

The relationships between the solution and other systems in operation within the organization are presented at the highest level.

Layer C1 may illustrate the overall logical architecture of Dynamics 365 Customer Engagement, its business role, and its connections to:

• ERP systems,
• document management platforms,
• internal and external APIs,
• other systems used within the organization.

This level provides an understanding of where the solution fits within the overall business environment.

C2 – units that store logic and data

In the C4 terminology, a container refers to an independently launched or deployed unit that stores business logic or data.

It is not a Docker container, a code module, or a library. In the Power Platform environment, the following can serve this purpose:

• Dataverse solutions,
• Power Apps apps,
• microservices running on Azure that handle integrations or the system's core logic.

Layer C2 thus outlines the main components of the solution and the division of responsibilities among them.

C3 – components that perform specific functions

At this level, the components responsible for a specific functionality are documented and made available as a service, an API endpoint, or an interface.

In the Power Platform ecosystem, components include:

• custom APIs,
• plug-ins,
• JavaScript libraries,
• PCF indicator lights.

When considering low-code and no-code tools, these may also include:

• flows,
• custom pages,
• Canvas components.

This allows both the code and the elements configured using the platform's tools to be documented using a single method.

C4 – Technologies Used in the Code

The most detailed layer may represent code that runs on an operating system, a cloud service, or a SaaS platform.

The following can be used in Power Platform solutions:

• C#,
• Visual Basic .NET,
• TypeScript or JavaScript,
• Power Fx.

Any notation of your choice can be used to describe them, such as UML, flowcharts, or dependency graphs.

A Practical Representation of the Solution's Architecture

For a Dynamics 365 or Power Platform project, the breakdown might look like this:

• context – business role, users, systems, and integrations,
• containers – Dataverse solutions, applications Power Apps and microservices Azure,
• components – APIs, plug-ins, libraries, controls, workflows, and canvas components,
• programming languages – C#, Visual Basic .NET, TypeScript, JavaScript, and Power Fx.

Documentation organized in this way makes it possible to discuss architecture at a level appropriate for the audience, without limiting the description solely to traditionally written code.