Methods · Topic T9

How a process should be turned into an intelligent operation

Reviewed October 21, 2026

It prints in full from the browser, on A4 or Letter.

Block 1

The problem

Turning a process into an intelligent operation without automating a bad process: modeling it before touching the technology, deciding what to automate and with which tool, and giving each decision the human control its risk calls for.

Summary in three lines

The process comes before the tool: a BPMN with owners, gateways, events and data serves to agree with the business, specify for technology and decide which events to capture in order to measure.
The tool is chosen by climbing a ladder: first the simplest intervention —fixing the process, a rule in code—, then flows and, only where interpretation is needed, an agent with limits.
Every automation is measured against the process it replaces and monitored afterwards: the pace is set by real capacity, not by the schedule, and autonomy grows with the evidence.

Block 2

The map

From an agreed process to an intelligent operation, rung by rung

Swipe to see the whole map.

Legend of shapes and colors

Actor — who does the work
Data — what is stored and read
Control — a rule that gets checked
Person — a person decides
External — what comes from outside

Reading the map, node by node

The process owner models it in BPMN; what is expected is checked against what was executed, which comes from the event log, and the process is fixed before its real capacity and its constraint are measured. With that measurement, what to automate is prioritized and the work starts on the simplest rung: code and rules; with no API, RPA on the interface; with connectors, low-code flows; with the data platform, n8n flows; and only where interpretation is needed, an agent in code. The agent acts within limits, under a human control that depends on the type of decision; the operation stays observable, leaves its trace in the event log and is measured, and the metrics go back to the process owner.

Node 1 Process owner (Person) — Whoever answers for the result of the process and decides what is automated, with which tool and with how much control.
Node 2 The process in BPMN (Data) — Lanes per owner, gateways with their rule, the events that trigger it and the data objects that travel between activities.
Node 3 Designed versus executed (Control) — Where what the procedure says and what the operation does drift apart: informal decisions, manual corrections and exceptions.
Node 4 Capacity and constraint (Control) — Standard time, effective capacity and the station that sets the pace of the whole flow, measured before anything changes.
Node 5 What to automate (Control) — Value, frequency, available data and the risk of being wrong: what is stable and worth it gets automated, not what is still under discussion.
Node 6 Event log (Data) — What happened, when, on which objects and who did it: the basis for comparing what was expected with what was executed.
Node 7 Code and rules (Actor) — A macro, a script or a query that applies explicit rules: the simplest rung and the first one tried.
Node 8 RPA on the interface (Actor) — A robot that repeats clicks and keystrokes where the system offers no API; it depends on the screen not changing.
Node 9 Low-code flows (Actor) — Flows between applications with connectors and approvals: deterministic, the same input gives the same output.
Node 10 n8n flows with data (Actor) — Flows that connect services, rules and agents, with a data platform that keeps every event so they can be observed.
Node 11 Agent in code (Actor) — Interprets language, retrieves knowledge or chooses between options within limits, with verifiable criteria; it comes in where a fixed rule is not enough.
Node 12 Human control per decision (Control) — Inform, recommend or execute: autonomy depends on the cost of being wrong and on whether the action can be reversed.
Node 13 Observable operation (Data) — Every run with its status, its time, its exceptions and its cost, recorded outside the component that does the work.
Node 14 Automation metrics (Control) — Cycle time, rework, errors and the manual work that remains, compared with the baseline of the process.

Connections

from Process owner to The process in BPMN (models)
from The process in BPMN to Designed versus executed (expected)
from Event log to Designed versus executed (executed)
from Designed versus executed to Capacity and constraint (is fixed)
from Capacity and constraint to What to automate (prioritizes)
from What to automate to Code and rules (starts with)
from Code and rules to RPA on the interface (no API)
from RPA on the interface to Low-code flows (with connectors)
from Low-code flows to n8n flows with data (with data)
from n8n flows with data to Agent in code (needs interpreting)
from Agent in code to Human control per decision (within limits)
from Human control per decision to Observable operation (operates)
from Observable operation to Event log (leaves its trace)
from Observable operation to Automation metrics (is measured)
from Automation metrics to Process owner (informs)

Block 3

The phases

1
Phase 1
Model the process before touching the technology
Inputs
- The process as it runs today, with its exceptions and its side files.
- The written procedures and the people who do each activity.
Activities
- Draw the process in BPMN: who does each activity, which decision splits the flow, which event triggers it and what information travels.
- Check the formal process against the executed one and record every divergence.
- Decide with the owner what is kept, what is transformed and what still needs agreement.
Artifacts
- The BPMN agreed with the process owner.
- The list of divergences between the formal and the executed process.
Who decides
The process owner.
Control that closes the phase
No automation starts on a process its owner has not agreed to.
Evidence
At Cafam, in 2020, the warehouse process the WMS expected and the one the warehouse carried out were not the same, and the tests existed to find every point where they diverged.
2
Phase 2
Measure real capacity and the constraint
Inputs
- The observed times of each operation and who performs it.
- The volumes, stations and queues of the whole flow.
Activities
- Calculate the standard time with pace rating and fatigue allowances.
- Find the station that sets the pace of the whole flow.
- Balance the flow toward the constraint, not speed up each station separately.
Artifacts
- The standard times of the operations.
- The capacity map with its bottleneck.
Who decides
The process owner, with whoever runs it.
Control that closes the phase
No automation target is set against nominal capacity.
Evidence
At Ceinfes, in 2018, speeding up scanning made no sense if manual capture could not keep up: balancing was not buying more scanners, but moving people toward the constraint and measuring each day the progress and the backlog of digitization.
3
Phase 3
Decide what to automate and with which tool
Inputs
- The agreed process, its capacity and its constraint.
- The value, frequency and risk of being wrong of each activity.
Activities
- Rule out what is solved by changing the process, clarifying a definition or improving the data.
- Choose the lowest rung of the ladder that produces the result.
- Write down why the rung below is not enough every time one is climbed.
Artifacts
- The prioritized queue of automations.
- The written tool decision for each one.
Who decides
The process owner, with whoever runs the technology.
Control that closes the phase
No agent where a fixed rule is enough, and nothing is automated without a baseline.
Evidence
At Banco Pichincha, on the ladder of instruments from the report to the agent, the right rung for churn and delinquency was the predictive model with the person deciding, not an agent; at Vesting, agents that acted within explicit limits and real-time monitoring.
4
Phase 4
Build with the human control each decision calls for
Inputs
- The chosen activity and its rung.
- The decisions it touches and what being wrong costs in each one.
Activities
- Specify each activity with inputs, rules, outputs, exceptions and verifiable criteria.
- Set what it informs, what it recommends and what it executes on its own, and under which conditions.
- Test against the definition of done before operating.
Artifacts
- The specification with its acceptance criteria.
- The autonomy matrix by type of decision.
Who decides
The process owner approves the level of autonomy.
Control that closes the phase
No high-impact action without human approval, and the definition of done is agreed beforehand.
Evidence
At Vesting the eleven-stage core process set each agent's level of autonomy —consult, recommend or execute, and under which conditions— before building it, and the definition of done was agreed beforehand, not shown afterwards.
5
Phase 5
Operate, observe and measure against the baseline
Inputs
- The events of every run.
- The baseline of the process before automating.
Activities
- Record every run with its status, its time, its exceptions and its cost.
- Compare what was executed with what was expected and with the baseline.
- Decide whether to correct the operation or update the process model.
Artifacts
- The dashboard of the automated operation.
- The exception log with its owner.
Who decides
The process owner, with product and operations.
Control that closes the phase
The component that does the work is not the only one that claims the work was done right.
Evidence
At Vesting n8n coordinated part of the agents' execution and Microsoft Fabric kept their events —sessions, requests, responses, times, statuses and token cost—, which Power BI put in front of product and operations: execution and observation were kept apart, because the component that does the work should not be the only one claiming it was done right.

Block 4

The design decisions

BPMN before the tool
When yes
When the process crosses areas, has exceptions or nobody has written down how it really runs: the diagram agrees with the business, specifies for technology and says which events to capture in order to measure.
When no
When the task belongs to a single person, with stable and known steps: writing it down is enough.
Why
Evidence
At Cafam every dispatch activity had to leave a record in the WMS, and if it did not, the control BI could not see it: BPMN comes before the data model, and the data model before any dashboard.
State of the field
The BPMN standard seeks a notation readily understandable by all business users and a standardized bridge between the design of a process and its implementation.^[1]
How to decide what to automate and with which tool: the simplest intervention that produces the result
When yes
Always: first check whether changing the process, clarifying a definition or improving the data is enough; then, the lowest rung that solves it —a rule in code before a flow, a flow before an agent—.
When no
When the activity is still under discussion or changes every week: automating it freezes the discussion inside a tool.
Why
Evidence
At Ceinfes the scheduling of teachers and consultants for more than 100 schools a year, done by hand in Google Calendar, did not need a system: it needed a VBA macro that optimized it with the constraints written down —availability, competence, location and each school's window—.
State of the field
Microsoft's HEAT guidance starts from the fact that not every process can be automated: it proposes picking each automation by its expected return and using process mining to discover which one to automate.^[5]
RPA only where there is no other door
When yes
When the system offers no API or connector, the screen is stable and the rules can be written down: a robot repeats the work on the interface.
When no
When an API or a connector exists, or the screen changes often: interface automation breaks with every redesign.
Why
State of the field
Desktop flows broaden Power Automate's robotic process automation (RPA) capabilities: they automate repetitive rule-based tasks on modern and legacy applications.^[7]
Judgment
A robot on the interface lasts as long as the screen does: it needs an owner and a review date from day one.
Deterministic flows for what must come out the same, agents for what needs interpreting
When yes
When the same input must always produce the same output —an approval, a load, a notification—, the step is a flow; the agent comes in only at the step that requires interpreting language, retrieving knowledge or choosing between options.
When no
When an agent is set to run a step a fixed rule solves: variability is gained and the traceability of the rule is lost.
Why
State of the field
In Copilot Studio agent flows are deterministic: they follow a rule-based path, and the same input always produces the same output.^[9]
Evidence
At Vesting n8n was a fundamental base for automating the agents' flows, not the whole architecture: the value lay in defining what information came in, what transformation happened, what result was expected and how an exception was handled.
Human control by type of decision
When yes
When a decision has consequences that cannot be reversed or its error is costly: the automation informs or recommends, and a person approves.
When no
When the action can be verified and reversed, and approving each case would turn the person into the bottleneck.
Why
Evidence
In the 11 portfolio agents each one's limits and what it «never» does are written in its technical sheet, and the Power BI Dashboard Builder has 5 human approval gates: no run closes without a person approving the result.
State of the field
Copilot Studio separates three layers of control: the deterministic one for critical or irreversible actions, an intermediate one with approval checkpoints for medium risk and the generative one for low-risk work, with explicit decision boundaries.^[11]
Measure the automation against the baseline of the process
When yes
Whenever an automation goes into operation: it is compared with the process it replaces —cycle time, rework, errors, the manual work that remains— and not with its demo.
When no
When there is no baseline: the process is measured first and automated afterwards.
Why
Evidence
At Cafam, inventory record accuracy was measured before and after the WMS implementation testing, and the VBA applications that replaced manual loads raised automation by 15% and contributed to cutting data errors by 50%.
State of the field
In Microsoft's automation maturity model, indicators to measure the benefits of automation and its effect on operational metrics are set from the first level.^[6]

Block 5

What is new in 2026

State of the field
Object-centric process mining
What changes from common practice
An event log no longer assumes a single case per process: OCEL 2.0 records events that touch several objects at once, the changes of those objects and their qualified relationships, with three exchange formats —SQLite, XML and JSON—, and Power Automate documents how to prepare an object-centric log —a CSV in Azure Data Lake or OneLake, or a delta table in a Fabric Lakehouse— to ingest it into its process mining.^[2]^[3]
Judgment
Process mining shows what was executed, not what should be: the agreed model is still needed to know which of the two gets corrected.
State of the field
Process mining to discover what to automate
What changes from common practice
Power Automate's process mining uses the event logs of the system of record to draw the real process with data and metrics; among its uses it lists seeing the actual steps, detecting noncompliant processes and discovering automation opportunities, and task mining looks at what happens on the desktop.^[4]
State of the field
Computer-using agents versus RPA
What changes from common practice
RPA follows predefined rules over the interface tree; a computer-using agent sees the screen, reasons and corrects itself. Microsoft recommends RPA when the interface is stable, the rules are clear and the volume is high, and the agent when interfaces shift or the decision is fuzzy.^[8]
Judgment
A computer-using agent does not replace the underlying question: if an API exists, the interface is still the wrong door.
State of the field
From the process to a flow that calls agents
What changes from common practice
When a process requires strict ordering, business rules and auditability, it can be appropriate to chain agents in a flow with a predefined sequence: each step with preconditions, post-conditions and thresholds, and human approval gates.^[10]
Judgment
An approved diagram is the best first specification of that sequence, as long as every activity declares what it receives, what it does and what it delivers.
State of the field
Design principles for an automation
What changes from common practice
Microsoft's HEAT guidance lists among the design principles of an automation logging, credential management and testing, the error handling and retry strategy, and the choice between API and interface.^[5]

Block 6

Failure modes and how to anticipate them

What breaks
Automating a bad process
How it shows up
The automation repeats the existing rework and exceptions faster.
Control that catches it
No automation on a process that has not been agreed and checked, formal against executed.
What breaks
Optimizing away from the constraint
How it shows up
One station goes faster, the queue grows at the next one and the total time does not change.
Control that catches it
Measure the whole flow and automate first where the constraint is.
What breaks
The robot that breaks with the screen
How it shows up
An RPA fails after an interface change nobody announced.
Control that catches it
An API or connector when they exist; RPA with an owner, a review date and a failure alert.
What breaks
An agent where a rule was enough
How it shows up
The same input produces different outputs at a step that had a fixed rule.
Control that catches it
A deterministic flow for what must come out the same; the agent only at the step that requires interpreting.
What breaks
An automation with no owner
How it shows up
A flow runs and nobody knows which activity it covers or what happens if it stops.
Control that catches it
Every automation with its owner, limit and the activity it covers, written down.
What breaks
Savings with no baseline
How it shows up
Savings are announced that nobody can compare with the process before.
Control that catches it
The baseline of the process is measured before automating.
What breaks
Autonomy before trust
How it shows up
An agent executes actions that were never reviewed while it only recommended.
Control that catches it
Gradual autonomy: inform, then recommend and, with evidence, execute.
What breaks
Exceptions nobody sees
How it shows up
The flow reports success and the case was left half done.
Control that catches it
The events of every run go to a platform separate from the one that executes.

Block 7

Metrics and controls

What is measured
Process cycle time
Threshold
Lower than the baseline, measured on the whole flow and not on one activity.
Who approves the step to production
The process owner.
What is measured
Manual work that remains
Threshold
Measured per activity and compared with the baseline.
Who approves the step to production
The process owner.
What is measured
Data errors and rework
Threshold
Below the baseline, with every exception recorded.
Who approves the step to production
Whoever runs the process.
What is measured
High-impact exceptions resolved by a person
Threshold
All of them.
Who approves the step to production
The process owner.
What is measured
Automations with a written owner and limit
Threshold
All of them, before operating.
Who approves the step to production
Whoever manages the automations.
What is measured
Divergences between what was modeled and what was executed
Threshold
Reviewed every cycle; none left without deciding whether the process or the model changes.
Who approves the step to production
The process owner.
What is measured
Actions executed without approval
Threshold
Only those that can be verified and reversed.
Who approves the step to production
The process owner, with risk.

The thresholds are examples of the method, not figures from a specific project.

Block 8

Evidence from projects

EvidenceLevel: Real use
BPMN before the technology, in four jobs
In four jobs the process was modeled in BPMN with Bizagi before touching the technology: at Inglopres, the machinery rental operation before implementing the ERP; at Ceinfes, the chain of scheduling, materials, test sittings and digitization; at Cafam, receiving, storage, picking and dispatch, checked against the WMS before testing it; and at Banco Pichincha, the analytics products placed within the decisions they had to support.
See where
EvidenceLevel: Real use
Inglopres: the time study with ILO allowances
At Inglopres, in 2016, the time study timed the operations, rated the pace of whoever performed them, calculated the standard time and applied fatigue allowances from the ILO table: an observed time is not a standard until it acknowledges the effort of whoever performs it.
See where
EvidenceLevel: Real use
Ceinfes: digitization balanced as a line
At Ceinfes, in 2018, the digitization of some 250 sheets per day was treated as a line of stations —2 for scanning, plus preparation, sorting, validation and reordering—; about 10% of the sheets required manual capture, and that station set the pace of the whole line.
See where
EvidenceLevel: Real use
Cafam: VBA tools with an owner and a limit
At Cafam, in 2020, what the WMS did not cover at the distribution center was solved with VBA tools that complemented it —available, useful and maintainable in that organization— and not with a new platform: they raised automation by 15%, helped cut data errors by 50% and kept running after go-live, as pieces with an owner and a limit.
See where
EvidenceLevel: Real use
Ceinfes: Kanban for requests, Scrum for projects
Between November 2017 and November 2018, at Ceinfes, Kanban was used for the technology area's flow of requests —each card, a visible request with its status and its owner— and Scrum for the technology projects, during the transition to a process-based management model supported by information systems.
See where
EvidenceLevel: Real use
Vesting: the eleven-stage core process, on n8n
Between August 2023 and January 2025, at Vesting, the eleven-stage core process —from the use case to observable operation— served as the framework to build the 27 agents in the inventory, with n8n as the automation base and their events in Microsoft Fabric.
See where
EvidenceLevel: Real use
The portfolio: the BPMN that generates itself
In the portfolio, the BPMN diagram of every piece is generated from the definition of its process by an in-house engine and validated at build time: if the definition changes, the diagram changes with it, and if it is malformed, publishing fails before it goes out.
See where
EvidenceLevel: Prototype
FORJA: from BPMN to an orchestration of agents
FORJA, one of the author's research lines, proposes opening up every BPMN activity with inputs, function and outputs, and its compiler turns the diagram into an orchestration of agents where every element traces to its realization; the step from BPMN to orchestration is developed in the publication on agent systems.
See where

Block 9

Limits and scope

Evidence
Process mining on a real event log is a method that would be applied, not a case run at a company; the closest was Vesting, where each of the 27 agents left its event trail and the core process defined what should happen.
Evidence
The internal details of Vesting's architecture, its own components and the exact implementation sequence are the organization's confidential knowledge: the piece cites the stages and the discipline, not the mechanisms.
Evidence
At Fundación CTIC the work has used n8n and the LangChain ecosystem, but the corpus names no deliverable built with them: the documented automation base is Vesting's.
Evidence
FORJA has its demonstrator —compiler, five processes, baseline and approval gates—, but whether professionals use it can only be shown with professionals, not with the prototype.
Judgment
The ladder names rungs this piece treats only as state of the field —RPA, low-code flows and computer-using agents—: the experience it claims is that of block 8, at the level the corpus gives it.
Judgment
What is worth doing differently today: measure the baseline of the process before the first automation, not when someone asks how much was saved.
Judgment
Automating a process nobody has agreed on turns a disagreement into code.

Block 10

Sources and review date

Reviewed October 21, 2026

[1]
ISO/IEC 19510:2013 Information technology - Object Management Group Business Process Model and Notation
IEC Webstore (ISO/IEC JTC 1) · July 15, 2013
https://webstore.iec.ch/publication/10695
[2]
OCEL (Object-Centric Event Log) 2.0 Specification
arXiv · March 4, 2024
https://arxiv.org/abs/2403.01975
[3]
Create an object-centric event log
Microsoft Learn · August 17, 2026
https://learn.microsoft.com/en-us/power-automate/object-centric-create-event-log
[4]
Overview of process mining and task mining in Power Automate
Microsoft Learn · August 28, 2026
https://learn.microsoft.com/en-us/power-automate/process-advisor-overview
[5]
Holistic enterprise automation techniques (HEAT)
Microsoft Learn · September 28, 2022
https://learn.microsoft.com/en-us/power-automate/guidance/automation-coe/heat
[6]
Microsoft Power Platform automation maturity model overview
Microsoft Learn · July 1, 2024
https://learn.microsoft.com/en-us/power-automate/guidance/automation-coe/automation-maturity-model-overview
[7]
Introduction to desktop flows
Microsoft Learn · August 23, 2026
https://learn.microsoft.com/en-us/power-automate/desktop-flows/introduction
[8]
Use agent tools to extend, automate, and enhance your agents
Microsoft Learn · October 5, 2026
https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/agent-tools
[9]
Agent flows overview
Microsoft Learn · June 18, 2026
https://learn.microsoft.com/en-us/microsoft-copilot-studio/flows-overview
[10]
Workflow-oriented multi-agent patterns
Microsoft Learn · February 3, 2026
https://learn.microsoft.com/en-us/agents/architecture/multi-agent-workflow-oriented
[11]
Apply generative orchestration capabilities
Microsoft Learn · September 18, 2026
https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/generative-orchestration

Summary in three lines

From an agreed process to an intelligent operation, rung by rung

Legend of shapes and colors

Reading the map, node by node

Connections

Inputs

Activities

Artifacts

Inputs

Activities

Artifacts

Inputs

Activities

Artifacts

Inputs

Activities

Artifacts

Inputs

Activities

Artifacts

BPMN before the tool

Why

How to decide what to automate and with which tool: the simplest intervention that produces the result

Why

RPA only where there is no other door

Why

Deterministic flows for what must come out the same, agents for what needs interpreting

Why

Human control by type of decision

Why

Measure the automation against the baseline of the process

Why

Object-centric process mining

Process mining to discover what to automate

Computer-using agents versus RPA

From the process to a flow that calls agents

Design principles for an automation

BPMN before the technology, in four jobs

Inglopres: the time study with ILO allowances

Ceinfes: digitization balanced as a line

Cafam: VBA tools with an owner and a limit

Ceinfes: Kanban for requests, Scrum for projects

Vesting: the eleven-stage core process, on n8n

The portfolio: the BPMN that generates itself

FORJA: from BPMN to an orchestration of agents