Process Before Platform
From AS-IS and BPMN to Power Platform and AI Agents
Low-Code platforms have dramatically reduced the distance between a business idea and a working application. A process that once required requirements documents, development teams, database scripts, integration code and several deployment cycles can now be prototyped in Power Apps or Power Automate in a matter of hours.
Generative AI has shortened this distance even further. Microsoft Copilot Studio allows us to describe an Agent in natural language, connect Knowledge, expose Tools and rapidly create an experience that can understand users and participate in business activities.
This speed is valuable, but it introduces a new architectural risk:
We can now build a solution before we fully understand the problem.
The traditional cost of software development created a natural barrier between an idea and its implementation. Building something was expensive enough that organizations usually performed at least some analysis before development began.
Low-Code weakens that barrier.
It is technically possible to hear “we need an approval process” in the morning and have a Power Automate Flow running by the afternoon.
But what exactly have we automated?
Is the existing approval actually necessary? Is the person approving it the correct authority? Are all requests supposed to follow the same path? What happens when information is incomplete? Which system owns the resulting transaction? What happens when the process fails after one system has already been updated?
These are not Power Automate questions.
They are process questions.
The same problem becomes more significant with AI Agents. If we begin with Copilot Studio before understanding the process, we can accidentally delegate decisions to an LLM that should have remained deterministic, human or controlled by another enterprise system.
The correct starting point is therefore not the platform.
It is the process.
This article develops a method for moving from a business problem to an appropriate Power Platform and Copilot architecture through a sequence that predates modern Low-Code:
Process Discovery → AS-IS → Analysis → BPMN → Process Improvement → TO-BE → Activity Classification → Technology Architecture
Only at the end do we ask whether the appropriate technology is SharePoint, Power Apps, Power Automate, Dataverse, an ERP, an API or a Copilot Studio Agent.
1. A Requirement Is Not a Process
Consider a common request:
“We need to automate our purchase requests.”
It sounds like a requirement, but from an architectural perspective it tells us remarkably little.
We do not know what causes a purchase request to exist. We do not know who can initiate one, which information is mandatory, whether different types of purchases follow different paths, how budget authorization works, which documents are required, which approvals are regulatory and which exist merely because “we have always done it this way.”
Most importantly, we do not yet know where the process begins or ends.
This distinction between a requirement and a process is fundamental.
A requirement describes something the organization wants. A process explains how a business outcome is produced.
The process may cross several applications and organizational boundaries. An employee might begin a request in a spreadsheet, send it through Outlook, receive approval in Teams, store supporting documentation in SharePoint and finally have somebody manually enter the approved transaction into an ERP.
From the employee’s perspective, all of that is one process.
From the technology perspective, it may involve five different systems.
This is why architecture should not begin by asking which Power Platform product should be used.
The first question should be:
How does the business capability actually work?
Section summary
| Concept | Question |
|---|---|
| Business need | What outcome does the organization need? |
| Requirement | What capability is being requested? |
| Process | How is the outcome currently produced? |
| Actor | Who participates? |
| Activity | What work is performed? |
| Business rule | What determines behavior? |
| Information | What data or documents are required? |
| System | Where does work or information reside? |
| Outcome | What indicates successful completion? |
2. Process Discovery: Finding the Real Process
Process discovery attempts to understand how work actually happens.
This distinction matters because organizations frequently have at least three versions of the same process.
The first is the documented process: what policies, procedures and training material say should happen.
The second is the perceived process: what managers and participants believe happens.
The third is the executed process: what actually happens in daily operations.
These versions are not necessarily identical.
A procedure might state:
Employee → Manager Approval → Procurement → ERP
Interviews might reveal something more complicated:
Employee → Excel → Email → Manager → Procurement → ERP
Observation might reveal the real process:
Employee → Excel → Email → Manager → Request returned → Employee corrects spreadsheet → Manager → Procurement → Missing attachment → Employee → Procurement → ERP
The difference between these models is not merely documentation noise.
It may reveal the actual business problem.
Perhaps the organization does not have an approval problem at all. Perhaps it has a data-quality problem that repeatedly causes requests to return to the requester.
If we automate only the visible approval step, we may improve a small part of the process while leaving its primary source of delay untouched.
Process discovery therefore requires evidence. Interviews are useful, but they should be combined where possible with existing documentation, application data, SharePoint history, workflow execution information, ERP records and other operational evidence.
Modern Process Mining extends this idea by reconstructing process behavior from event data. This does not replace interviews or business analysis. It provides another perspective: people explain why they believe the process behaves as it does, while execution data can help reveal how the process actually behaves.
Section summary
| Discovery source | What it can reveal | Limitation |
|---|---|---|
| Interviews | Intent, rules and exceptions | Can reflect perception |
| Procedures | Expected process | May be outdated |
| Observation | Actual human behavior | Limited sample |
| SharePoint history | Document/list activity | Only part of the process |
| Flow history | Automation execution | Only automated steps |
| ERP records | Transactional events | Limited business context |
| Process Mining | Patterns, variants and bottlenecks | Depends on event-data quality |
3. Building the AS-IS Model
Once the process has been discovered, we can construct an AS-IS model.
The purpose of AS-IS is not to design the future solution. Its purpose is to establish a credible representation of the current situation.
This distinction is important because analysts are naturally tempted to fix problems while documenting them.
If an employee currently copies information manually from SharePoint into an ERP, that manual activity belongs in the AS-IS model even if we already know that an API could eliminate it.
The AS-IS should describe reality.
Suppose our purchasing process contains the following sequence:
Employee prepares request → Manager reviews → Procurement validates → Finance verifies budget → ERP transaction is created → Employee is notified
At first glance this appears reasonable.
But deeper analysis may reveal that the request is repeatedly returned because required information is missing. Procurement may maintain a separate spreadsheet to track requests. Finance may re-enter values already provided by the employee. ERP information may later be copied back into SharePoint manually.
These details matter because they reveal handoffs, duplication and potential failure points.
A useful AS-IS model therefore captures not only the “happy path” but also the significant exceptions and rework loops.
That is where many of the real costs of a business process exist.
Section summary
| AS-IS dimension | What we want to discover |
|---|---|
| Start | What initiates the process? |
| Activities | What work is actually performed? |
| Actors | Who performs it? |
| Systems | Which applications participate? |
| Data | What information moves? |
| Documents | What supporting content is required? |
| Decisions | Where does the path change? |
| Handoffs | Where does responsibility change? |
| Rework | Where does work return? |
| End | What constitutes completion? |
4. Measure Before Automating
Once the AS-IS process is visible, we can ask a much more useful question than “what should we automate?”
We can ask:
Where is the process actually failing?
This reconnects modern Low-Code architecture with the quality-management traditions that became influential during the 1980s and 1990s.
Suppose a purchase request requires ten days from submission to ERP creation.
The number alone tells us little.
Process analysis might reveal that only forty minutes of those ten days represent actual work. The rest is waiting.
Perhaps two days are spent waiting for a manager. Three days are lost because incomplete requests return to the employee. Another day is spent transferring information manually. Two more days are consumed because Procurement processes requests in batches.
If we automate only the thirty-minute ERP entry, we have technically automated the process but barely changed its business performance.
This distinction between processing time and waiting time is extremely important.
The same applies to defects and rework. A process may appear slow because employees work slowly, when the actual problem is that 35% of requests arrive incomplete and must be processed twice.
Automation without measurement can optimize the wrong activity.
Section summary
| Metric | What it reveals |
|---|---|
| Cycle time | Total elapsed process time |
| Processing time | Time actually spent working |
| Waiting time | Time spent between activities |
| Rework rate | How frequently work must be repeated |
| Error rate | Frequency of incorrect outputs |
| Handoffs | Number of responsibility transfers |
| Process variants | Different execution paths |
| Automation rate | Portion already automated |
| Exception rate | Frequency of nonstandard execution |
The first improvement opportunity is not necessarily the activity that consumes the most technical effort. It is the activity whose improvement produces the greatest business value.
5. BPMN as an Analytical Tool
Once we understand the AS-IS process, BPMN becomes valuable.
Business Process Model and Notation should not be viewed simply as a prettier way to draw flowcharts. Its real value is conceptual discipline.
A BPMN model forces us to distinguish between events, activities, decisions, participants and communication.
A Start Event forces us to define what actually initiates the process.
A Task forces us to identify work that needs to be performed.
A Gateway forces us to understand why the process follows one path rather than another.
A Lane makes organizational responsibility visible.
A Message Flow exposes communication between participants.
An End Event forces us to establish what successful or unsuccessful completion actually means.
These questions become extremely useful when we later design a Power Platform architecture.
For example, if a BPMN model contains an activity named “Approve Purchase Request,” we can ask whether that activity represents a business rule or human authority.
Those are completely different things.
A rule such as:
Amount > 10,000 → CFO approval required
can be evaluated deterministically.
But the actual decision:
CFO approves the purchase
represents organizational authority.
An LLM should not silently collapse those two concepts into one “intelligent decision.”
BPMN helps us see the distinction before implementation begins.
Section summary
| BPMN concept | Architectural question |
|---|---|
| Event | What starts or changes the process? |
| Task | What work must occur? |
| Gateway | What determines the path? |
| Pool | Which participant or organization is involved? |
| Lane | Who is responsible? |
| Message | What communication crosses boundaries? |
| Data | What information is consumed or produced? |
| End Event | What defines completion? |
BPMN therefore becomes a bridge between business understanding and solution architecture.
6. Do Not Automate Waste
After documenting the AS-IS process, the next step should not automatically be implementation.
The process should first be challenged.
This is one of the most important lessons inherited from Business Process Reengineering and quality-management approaches.
Suppose an activity exists because one department historically printed a document, signed it and sent it to another department. The organization later replaced the paper with a PDF attachment but preserved the same sequence of approvals.
Power Automate could reproduce that sequence beautifully.
That does not prove that the sequence should continue to exist.
This creates an important distinction:
Automation asks how an activity can be executed more efficiently. Process improvement first asks whether the activity should exist at all.
We should therefore examine duplication, unnecessary approvals, manual data transfer, repeated validation, excessive handoffs and controls that no longer correspond to current risks.
The best automated activity is sometimes an activity that has been eliminated.
Section summary
| AS-IS observation | Question before automation |
|---|---|
| Repeated data entry | Why is the same data entered twice? |
| Multiple approvals | Does each approval represent real authority? |
| Spreadsheet tracking | Why is the System of Record insufficient? |
| Email handoff | Is explicit workflow needed? |
| Manual validation | Can validation occur earlier? |
| Manual copying | Can systems integrate directly? |
| Repeated corrections | Is initial data capture inadequate? |
| Long waiting time | What causes the queue? |
This prevents Low-Code from becoming merely a faster mechanism for institutionalizing inefficient processes.
7. Designing the TO-BE Process
Only after understanding and challenging the AS-IS process should we design the TO-BE process.
The TO-BE model describes how the business should operate after improvement.
Importantly, TO-BE should initially remain technology-neutral.
Instead of immediately saying:
“Power Apps collects the request.”
we might describe:
“Employee submits a structured purchase request.”
Instead of:
“Power Automate validates the amount.”
we describe:
“The request is automatically validated against purchasing rules.”
Instead of:
“Copilot Studio reads SharePoint.”
we describe:
“The employee can retrieve relevant procurement policy during request preparation.”
This separation prevents technology from prematurely constraining process design.
Once the TO-BE process is coherent, technology can be mapped onto it.
A simplified evolution might therefore be:
AS-IS
Employee → Excel → Email → Manager → Procurement → Missing Information → Employee → Procurement → ERP
TO-BE
Employee → Structured Request → Automatic Validation → Manager Approval → Procurement Review → ERP Transaction → Notification
The improvement is not the introduction of Power Platform.
The improvement is the redesigned process.
Power Platform will implement appropriate parts of it.
Section summary
| AS-IS | TO-BE objective |
|---|---|
| Unstructured request | Structured information |
| Late validation | Early validation |
| Repeated correction | Prevent incomplete submission |
| Email routing | Managed workflow |
| Duplicate data entry | Integrated data transfer |
| Manual tracking | Process visibility |
| Undefined ownership | Explicit responsibility |
| Informal exceptions | Controlled exception paths |
8. Classify the Work Before Selecting the Technology
Now we reach the point where this process-analysis methodology becomes particularly valuable for AI architecture.
Every significant activity in the TO-BE process should be classified before selecting technology.
An activity may be deterministic. Given the same inputs and rules, we expect the same result.
Another activity may be transactional. It modifies authoritative enterprise information.
Another may require human authority.
Another may be primarily informational.
And some activities may genuinely require semantic interpretation, where generative AI can provide significant value.
Consider the employee’s purchase justification.
Checking whether Amount > 10,000 is deterministic.
Creating the approved purchase requisition in ERP is transactional.
Approving the expenditure is an exercise of organizational authority.
Retrieving the procurement policy is informational.
Summarizing an unstructured business justification is generative.
These activities should not be implemented using the same mechanism merely because one platform technically allows it.
Section summary
| Activity type | Characteristics | Example |
|---|---|---|
| Deterministic | Explicit rules | Evaluate threshold |
| Transactional | Changes authoritative state | Create ERP requisition |
| Human | Requires authority/judgment | Approve expenditure |
| Informational | Retrieves trusted information | Get procurement policy |
| Integration | Moves data across systems | SharePoint → ERP |
| Generative | Interprets ambiguous/unstructured content | Summarize justification |
| Conversational | Benefits from natural interaction | Collect request context |
This classification gives us something extremely important:
a rational basis for deciding where AI belongs.
9. Only Now Should We Open the Microsoft Toolbox
At this point we finally have enough information to make technology decisions.
We know the business objective.
We know the AS-IS process.
We understand the bottlenecks.
We have designed the TO-BE process.
We have identified the actors, rules, information and authoritative systems.
And we have classified the activities.
Now Power Platform becomes a toolbox rather than a starting point.
A structured user interface may suggest Power Apps. Document-centric Knowledge may naturally belong in SharePoint. Deterministic workflow can be implemented in Power Automate. Complex relational business data may justify Dataverse. An authoritative financial transaction should probably remain in the ERP. Integration may use a Connector or REST API.
And semantic interpretation may justify Copilot Studio.
This produces a fundamentally different architecture from simply placing an Agent in front of every system.
Section summary
| Business responsibility | Candidate technology |
|---|---|
| Documents / policies | SharePoint |
| Structured application UX | Power Apps |
| Workflow / routing | Power Automate |
| Relational business data | Dataverse |
| Authoritative transaction | ERP / line-of-business system |
| Integration | Connector / REST API / appropriate integration layer |
| Enterprise identity | Microsoft Entra ID |
| Knowledge retrieval | Copilot Studio Knowledge |
| Natural-language interaction | Copilot Studio |
| Semantic interpretation | LLM / Agent |
| Organizational authorization | Human approval / security model |
The critical principle is that technology selection follows responsibility classification.
10. Where Copilot Studio Finally Enters
Only now are we ready to ask whether an Agent should participate.
Suppose our redesigned purchasing process contains an activity where employees describe what they need in natural language.
An Agent could help interpret that request.
The Agent could retrieve procurement policies from approved SharePoint Knowledge and explain which information is required.
It might help transform an unstructured description into a structured request.
It could call a Tool that invokes Power Automate.
Power Automate could then execute deterministic validation and workflow.
A manager could authorize the request.
An ERP API could create the authoritative transaction.
The architecture becomes:
Employee
↓
Copilot Studio Agent
Interpret request and provide conversational interaction
↓
SharePoint Knowledge
Retrieve approved procurement information
↓
Tool / Power Automate
Execute deterministic process
↓
Human Approval
Exercise organizational authority
↓
ERP
Create authoritative transaction
↓
Agent
Communicate the outcome
This is a fundamentally healthier architecture than:
Employee → AI → Everything
The Agent has a role.
It does not own the entire process.
This aligns with the principle we have already established in our Copilot Studio studies: once Agents participate in real business processes, BPMN should help identify events, activities, gateways, actors, systems and data before determining AI opportunities and Agent architecture.
11. Process Architecture Becomes Agent Governance
There is another consequence of beginning with the process.
It helps us define Agent boundaries.
If the process model establishes that a manager owns the approval decision, then the Agent should not independently approve the request.
If ERP owns the purchase transaction, the Agent should not become an alternative System of Record.
If Finance owns the purchasing threshold rules, those rules should not exist only as natural-language Instructions inside an Agent.
This is where process architecture becomes AI governance.
We can determine not only what the Agent can technically do, but what it should be authorized to do.
This becomes increasingly important as Agents acquire Tools and event-driven capabilities.
A conversational Knowledge Agent has limited operational impact.
An Agent capable of calling transactional systems has a very different risk profile.
Our broader architecture therefore needs to distinguish interpretation, recommendation, deterministic execution, human authority and authoritative system transactions.
Section summary
| Responsibility | Appropriate owner |
|---|---|
| Interpret natural language | Agent / LLM |
| Retrieve approved Knowledge | Knowledge/Retrieval |
| Evaluate fixed threshold | Deterministic rule |
| Execute workflow | Power Automate |
| Authorize expenditure | Human |
| Store authoritative transaction | ERP |
| Enforce access | Identity/security architecture |
| Explain outcome conversationally | Agent |
The question therefore evolves from “What can the Agent do?” to “What should the Agent be responsible for?”
12. A Repeatable Architecture Method
The ideas developed throughout this article can be consolidated into a repeatable method for Power Platform and Copilot projects.
We begin with the business problem rather than the technology.
We discover the process rather than assuming that the documented procedure represents reality.
We create an AS-IS model.
We measure performance and identify bottlenecks, rework and unnecessary activities.
We use BPMN to make actors, events, decisions and responsibilities explicit.
We challenge the existing process before automating it.
We design a technology-neutral TO-BE process.
We classify each important activity according to whether it is deterministic, transactional, human, informational, integrational or generative.
Only then do we select the appropriate Microsoft and enterprise technologies.
The resulting sequence is:
Business Problem
↓
Process Discovery
↓
AS-IS
↓
Measurement and Quality Analysis
↓
BPMN
↓
Process Improvement
↓
TO-BE
↓
Activity Classification
↓
Responsibility Mapping
↓
Technology Selection
↓
Power Platform / Copilot Studio / Enterprise Systems
↓
Implementation
↓
Measurement
↓
Continuous Improvement
This cycle is more important than any individual Power Platform product.
Conclusion
The extraordinary advantage of Low-Code is speed.
The extraordinary danger of Low-Code is also speed.
We can implement a process before understanding it. We can automate an activity before questioning why it exists. We can connect systems before defining ownership. And now, with generative AI, we can give an Agent operational capabilities before deciding whether an LLM should participate in those decisions at all.
The response to this problem is not to slow technological innovation.
It is to restore process thinking to the beginning of solution architecture.
Process Discovery helps us understand reality.
AS-IS modeling makes that reality visible.
Quality analysis tells us where the actual problems are.
BPMN exposes events, activities, decisions, actors and responsibilities.
TO-BE design allows us to improve the process before automating it.
Activity classification separates deterministic computation, human authority, transactions and generative reasoning.
Only then should Power Platform and Copilot Studio enter the architecture.
The result is a fundamental change in perspective:
Do not begin by asking what Power Platform can automate. Begin by understanding what the business is trying to accomplish.
And for AI Agents, the principle becomes even more important:
Do not begin by asking what the Agent can do. Begin by understanding the process well enough to decide what the Agent should do.
This prepares the next question in our progression.
Once the process has been discovered, measured, improved and classified, we can finally investigate where generative intelligence genuinely creates value.
That is the subject of the next article:
Finding Where AI Belongs in a Business Process — Deterministic Automation, Human Authority and Generative Reasoning.
