Open a Zapier zap, a Make scenario, an n8n workflow or a Power Automate flow and the screen shows boxes joined by arrows, with branches where the logic splits. It looks exactly like a process diagram.
It is an execution graph, and the difference is not a matter of vocabulary.
An execution graph answers one question: what does this tool do. A process model answers a different one: how does this work get done. The first is a subset of the second, cropped to the part that one vendor happens to run, and the cropping removes most of what a business actually needs to reason about.
What the frame leaves out
The canvas begins where the automation begins. That sounds obvious until you look at where the automation actually begins in most real workflows: three steps into the process, after a person has already read something, decided something and typed something.
Four categories of content sit permanently outside the frame.
The human steps. Somebody reviewed the request before it hit the trigger. Somebody will look at the output afterwards and occasionally send it back. Neither appears, so a canvas of nine nodes can represent about thirty percent of the elapsed time in a workflow, and reading it gives no hint that the other seventy percent exists.
The boundaries. A process model has pools and lanes because work crosses between participants, and crossings are where cases wait. An execution graph has one participant: itself. There is no lane for the customer, the supplier, or the office, so the most expensive structure in most processes is unrepresentable by construction.
The exceptions handled off-platform. The canvas can show its own error handling: retry three times, then post to a channel. It cannot show what happens next, which is usually that a specific person reads that channel, works out what went wrong, calls the supplier, and fixes it by hand. That step is real work, it happens weekly, and it exists in nobody’s documentation. This is the same gap that leaves nobody owning the exceptions, arriving through the tooling instead of the org chart.
The reason. A canvas records what was configured. It has no field for why. Eighteen months later there is a filter excluding records where a status field equals a particular value, and nobody alive knows whether that is a business rule, a workaround for a bug that has since been fixed, or a mistake that has been quietly dropping four records a month. Removing it is a gamble; keeping it is a gamble. The information needed to decide was never captured, because the artifact has nowhere to put it.
The portability question, answered honestly
The usual argument for a standard notation is portability, and the usual version of that argument overstates itself, so here is the accurate one.
BPMN 2.0 defines an XML serialization of the model plus a diagram interchange format for the visual layout. In principle a diagram drawn in one tool opens in another. In practice the Object Management Group runs a Model Interchange Working Group that has held annual interchange demonstrations since 2013, and it exists because moving models cleanly between tools still causes trouble. Vendors interpret parts of the specification differently, and round-tripping a complex model can lose detail.
So the claim is not that BPMN is perfectly portable. The claim is narrower and holds up better.
An open, documented format with an ISO number, a public specification and a working group fighting for interoperability degrades gracefully. Worst case, the XML is still readable text, and a person can reconstruct the model from it.
A proprietary export degrades to nothing. The JSON that comes out of an automation platform describes that platform’s node types, its connector names, its expression syntax and its internal identifiers. Nothing else consumes it, and its meaning depends on documentation the vendor controls.
And there is a guarantee below both of those that is worth more than either: a diagram on a page, in standard shapes, is readable by a person indefinitely. It does not depend on any software still existing.
The test that settles it
One question, and it takes about ten seconds to ask.
If you moved to a different automation platform next quarter, what would you work from?
If the answer is that somebody would open the current tool, read through the nodes, and rebuild the equivalent logic on the new one, then the process was never documented anywhere. The tool became the documentation at some point, without a decision being made, and the migration cost is now the cost of reverse-engineering your own operation.
That answer is extremely common and it is not a disaster. It is a signal that one artifact is missing, and the artifact costs an afternoon. It is the same structural question as keeping the model swappable: the thing that makes a vendor decision reversible is having written down what you wanted separately from how you got it.
The stakes rise with what is built on top. An automation running a two-step notification is fine either way. An agentic system where the tool canvas is the only record of the sequence, the approvals and the exception branches is a system whose orchestration is undocumented, and the questions that matter later cannot be answered without the vendor’s interface open.
Where the canvas is genuinely better
The fair counterweight, because this is not an argument for replacing one artifact with the other.
The canvas is always current. It is the thing running, so it cannot drift from reality. A process model on a shared drive can be nine months stale and confidently wrong, which is worse in some ways than having no model at all, because people trust it.
The canvas is also precise in ways a drawing is not. It contains the actual field mappings, the actual filter conditions, the actual retry counts. Those details matter and no sensible process model tries to carry them.
The relationship is the one between a floor plan and the wiring behind the drywall. The plan says where the kitchen is and why. The wiring diagram says which breaker feeds which outlet. An electrician needs the second. Anyone deciding whether to move the kitchen needs the first, and nobody has ever successfully derived one from the other.
What to actually do
Keep one page above the tool, and keep it honest with one rule: it gets updated when the process changes, not when the tool changes.
That rule is the whole discipline. Changing a connector, renaming a node, splitting one step into two for technical reasons: none of that touches the page. Adding an approval, moving ownership of a step, introducing a new exception path: all of that does. The page tracks intent, the canvas tracks implementation, and they change on different clocks.
Practically, the page holds seven things and fits on one sheet:
- The trigger, named as a business event rather than a webhook.
- The steps in order, in the words the business uses.
- A lane for each participant, including the ones you do not control.
- Every branch, with what decides it.
- Every exception path, each terminating somewhere, at least one of them at a person.
- Which steps the software runs and which ones a person does.
- The reason for anything that would look arbitrary to a stranger.
Nine shapes are enough to draw all seven. Store it beside the tool’s own export, in the shared drive, with a date on it. The cost is an afternoon and about twenty minutes a quarter, and the return arrives on the day somebody asks what would happen if you switched platforms, or the day the person who configured the whole thing gives notice.
The part worth carrying out the door
An automation canvas is a drawing of what one vendor’s software does. It is accurate, always current, and structurally incapable of holding the human steps, the boundaries, the offline exceptions or the reasons.
A process model holds those, does not execute anything, and stays readable when the tool is gone.
Keeping both is not duplication, because they answer different questions and change on different schedules. Keeping only the canvas means the operation is documented in a format one company controls, and the bill for that arrives the quarter you decide to change your mind.