From BPMN to Power Platform Architecture

Translating Business Processes into SharePoint, Power Automate, Copilot Studio and Enterprise Systems

The previous articles established three principles.

Low-Code does not mean Low-Knowledge.

Process should come before platform.

Responsibility should come before intelligence.

We can now move from principles to architecture.

At this stage, we already have something extremely valuable: a TO-BE business process. We understand its actors, activities, decisions, information flows and business outcomes. We have also classified its activities according to their fundamental characteristics: deterministic, human, informational, transactional, integrational or generative.

The next challenge is translating that business model into a technology architecture.

This is where Power Platform architecture often goes wrong.

A process diagram is not a solution architecture. A BPMN Task does not automatically become a Power Automate action. A Lane does not become a Power App. A Gateway does not necessarily become a Flow condition. Most importantly, a business activity involving language does not automatically become a Copilot Studio Agent.

BPMN describes the business process.

Solution architecture describes the technical capabilities that support that process.

The architect’s responsibility is to build the bridge between them.

For this article, we will use a single scenario throughout: an internal corporate purchase request.

The employee describes a purchasing requirement. The organization needs to validate the request, provide relevant procurement policy, determine the appropriate approval path, obtain authorization and ultimately create a transaction in an ERP.

The process is deliberately simple enough to understand but rich enough to involve the major architectural concepts we need:

Employee → Agent → Knowledge → Workflow → Human Approval → Integration → ERP

Our objective is not to place Microsoft technology everywhere.

Our objective is to determine which component should own each responsibility.

1. Start With the Business Architecture

Before mapping technologies, we need to preserve the process independently from its implementation.

Consider the following simplified TO-BE process:

Purchase Requirement Identified

↓

Capture Purchase Requirement

↓

Validate Required Information

↓

Analyze Business Justification

↓

Retrieve Applicable Procurement Policy

↓

Determine Approval Path

↓

Manager Reviews Request

↓

Approved?

↓

Create Purchase Requisition

↓

Return Requisition Number

↓

Notify Employee

↓

Process Completed

At this point, none of these activities needs to be associated with Power Platform.

That is intentional.

“Capture Purchase Requirement” describes a business capability.

It does not yet mean Power Apps.

“Analyze Business Justification” describes an analytical capability.

It does not yet mean Copilot Studio.

“Create Purchase Requisition” describes a business transaction.

It does not yet tell us whether the implementation uses a Connector, Power Automate, REST API, custom integration service or another mechanism.

Separating business architecture from technology architecture prevents products from distorting the process model.

Section summary

2. Add Responsibility Before Technology

The next step is not assigning products.

It is assigning responsibility.

For every activity, we ask what kind of responsibility it represents.

Capturing an employee’s description may involve conversational interaction.

Checking that required fields exist is deterministic validation.

Analyzing free-text justification is semantic interpretation.

Retrieving procurement policy is Knowledge retrieval.

Determining whether CFO approval is required may be deterministic.

Actually approving the expenditure represents human authority.

Creating a purchase requisition is a transaction against an authoritative enterprise system.

These distinctions are more important than the technology names.

We can therefore enrich the process:

Capture Requirement — Conversational

↓

Validate Data — Deterministic

↓

Analyze Justification — Generative

↓

Retrieve Policy — Knowledge

↓

Determine Approval Path — Deterministic

↓

Approve — Human Authority

↓

Create Requisition — Transactional

↓

Return Result — Integration

Now the technology architecture has something stable to map against.

Section summary

3. Introduce Systems of Record

Before selecting Power Platform components, another architectural question must be answered:

Which system owns which information?

This is the concept of the System of Record.

Suppose the organization stores procurement policies in SharePoint. SharePoint is therefore authoritative for those documents.

Suppose requests under preparation are stored in Dataverse or a SharePoint list. That platform may be authoritative for the request during its workflow lifecycle.

Suppose approved purchase requisitions belong to the ERP. Once the ERP creates the requisition, the ERP becomes authoritative for that transaction.

These distinctions prevent data ownership from becoming ambiguous.

A common Low-Code anti-pattern is duplicating business state across SharePoint, Dataverse, Excel and ERP without defining which copy is authoritative.

An Agent makes this even more dangerous because it can present information from multiple systems as if all sources had equal authority.

They do not.

If the Agent says:

“Your purchase requisition is PR-10482 and its status is Approved.”

we need to know where that fact came from.

Was it generated from conversational memory?

Was it stored in a SharePoint item?

Or did the ERP return the authoritative status?

Architecture requires an answer.

Section summary