What a process diagram leaves out
The diagram was approved. It is on the wall, it is in the wiki, and the integration built from it has run for a year without a failed deployment. Then the thing goes wrong, and the meeting about why it went wrong spends ninety minutes on a question the diagram cannot answer: who was supposed to tell whom, and by when.
Nothing was drawn incorrectly. The question was never in the drawing.
What BPMN is good at, which is a great deal
BPMN is not a picture of a process. It is an execution language with a picture attached, and that is its strength. A gateway is a branch. A token moves. A timer boundary event is a deadline your engine will actually enforce. Hand the XML to Camunda or Flowable and something runs — the same model the analyst drew, not a redrawing of it, which is the gap every earlier notation died in.
It is also a standard, which is worth more than any individual feature. One business process diagram means the same thing in four tools and to a contractor you have never met. That is rare and it took a committee to get it.
For orchestrating systems, none of this is improved on by drawing loops between named people. If the work is call this API, wait for the callback, retry three times, write to that queue, BPMN is the right instrument and this one has nothing to offer you.
A great deal of workflow has no people in it at all
This is the honest half of the objection and it deserves to go first. Much of what is called workflow is machinery talking to machinery: a file lands, a job transforms it, a record updates, a webhook fires. There is no request in it, nobody agreed to anything, and nobody is going to be disappointed. Drawing that as a network of promises would be a costume, not a model.
So the claim here is not that every workflow is secretly a conversation. It is narrower and, I think, harder to argue with: a system-to-system step is almost never the whole path, and the parts either side of it are made of people. The file lands because somebody was asked for it. The record updates so that somebody can rely on it. The webhook fires and, three steps later, a person is expected to have done something about it.
The system is acting for somebody, and that somebody is still answerable
Take the automatic approval — under five hundred, clears itself, no human involved. It is genuinely automatic and it is genuinely right to automate it. But it is not a moment with nobody in it. Somebody decided that under five hundred needs no judgement, and that person is answerable for the decision in exactly the way they would be if they approved each one by hand. The act was delegated. The accountability was not, and cannot be.
That is why this notation draws an automated moment differently rather than leaving it out. Not because automation is suspect — it is usually the right call — but because you should be able to look at a design and see, at a glance, which moments run by rule and whom each rule is acting for. The interesting question about an integration is not whether it runs. It is: when it silently stops running at three in the morning, who was owed what, and how long before anybody is entitled to notice?
BPMN records the retry policy. It does not record the answer to that.
Agents may be the best glue there has ever been
Integration has always been the expensive, boring part: adapters, schema mapping, retries, reconciling one system's idea of a customer with another's. BPMN engines, ESBs and the whole integration-platform industry exist because that work is enormous and nobody enjoys it.
A model handed a set of tools is remarkably good at it. It can read an API it has never seen, cope with a field that changed name last week, and recover from an error that would have thrown. It is entirely plausible that this is the last integration layer anybody builds by hand, and that within a few years the wiring between systems stops being a project and becomes a sentence. If that happens it will be a genuine achievement and BPMN will have been part of what it replaces.
And it will not touch any of this. Glue joins systems. It does not decide who was owed what. Make the connection between two systems perfect, instant and free, and every question here is still open: who asked for this, were they in a position to be told no, what would count as done, and who says whether it was. An agent can do the work. It cannot be the one who wanted it, the one who was free to refuse, or the one who is disappointed — only a person can promise is that argument at length.
There is a sharper version. The better the glue, the more the layer above it matters, because what improves is the speed of whatever was already there. If the commitments underneath are vague, automating on top makes the vagueness faster: the same unaccountable work moving between the same queues, with better telemetry on how long it sat. That is not an argument against agents. It is an argument for knowing what they are carrying.
A swimlane looks like it says who, and does not
This is the near miss, and near misses are more expensive than absences, because you stop looking.
A lane says which role a task sits in. It does not say who asked for it, whether they were in a position to say no, what would count as done, or who gets to say it was what they wanted. Those are four different facts about one piece of work and a lane carries none of them. It carries a fifth: where the box goes.
Watch what that costs. Two lanes, an arrow between them, and the arrow means this is now yours. Nothing in the notation can express that the person in the second lane could have declined, or countered, or asked what "done" meant before agreeing. Not because the modeller forgot. Because there is no symbol for it. A process diagram in which nobody can refuse anything is not a description of a workplace; it is a description of a workplace where refusal has already been designed out, and the diagram cannot tell you which of those two you are looking at.
A diagram says what order. It does not say when
Sequence is not duration. An arrow from one box to the next says this follows that, and says nothing about whether the gap is an afternoon or a fortnight — which is the only thing anybody downstream actually wants to know.
Some tools bolt simulation on beside the diagram, and where they do, the question they answer is a plant question: resource utilisation, queue depth, where the bottleneck sits if you run ten thousand instances. Useful, and not the same question as the bay was promised in two weeks, so which promises have to hold for that to be true, and has anybody actually made them?
Here each commitment carries its own time and only its own — what this piece of work is expected to take, between the two people it is between. The run does the arithmetic and says which day each moment is reached, and therefore which day each person is holding something. That is where a date somebody gave in a meeting turns out to be a sum of other people's promises, several of which nobody has made yet.
Two limits on that, stated the same way the rest of this site states them. It models work, not waiting: an answer arrives the instant it is asked for, where in life a request sent on Friday is answered on Monday. And every figure is the earliest the design allows if nobody sits on anything, and nobody has ever not sat on anything. It is not a forecast. It is the floor — and a design whose floor is already past the date it promised has told you something before anybody has had to live in it.
Four things a diagram is never wrong about
It is never wrong about them because it never claims them:
Who asked. An arrow into a task says work arrived. It does not say anybody wanted it. A great deal of work in real organisations arrives because a rule fired, and on a diagram that is indistinguishable from a person asking.
Whether they could have said no. Declining, countering and revoking are ordinary moves that cost something socially, and every competent person makes them. A design with nowhere to put them does not remove the cost. It removes the option.
What would count as done. "Completed" is a status: a token left the box. It is not a condition of satisfaction, and the word satisfaction is doing real work in that phrase — the conditions are on the customer being satisfied, not on the performer feeling finished. Those two come apart constantly, and most of what gets called a quality problem was a conditions problem nobody had the conversation about. There is no field for it in BPMN because there is nobody in BPMN for it to be a condition on.
Who accepts. This is the one that matters most and is missing most completely. In BPMN a task ends when the performer says it ends. There is no move in the language for the person who wanted it saying yes, that was what I needed — or, far more valuable, no, it was not. So a diagram cannot show you work that was finished and never accepted, which is the most common expensive failure in any organisation I have looked at.
Somebody is standing behind each of these
Strip out the notation and the argument underneath is older and plainer than any of it. A business is not a machine that processes items. It is people making promises to other people and keeping them, or not, and everything a company sells is somebody's promise that the thing will be there and will work. That claim is Fernando Flores's and the essay on it makes it properly; the point here is only what it costs to draw the work as though it were untrue.
If nobody stands behind a step, nobody can be disappointed by it, and nothing about it can go wrong in a way anybody notices. That sounds abstract until something is late.
An alert is worth having when it has a name in it
Every serious workflow product monitors, and what it monitors is duration. An instance has been in a state too long, a threshold is passed, a queue is deep. So the alert says: instance 4471 has exceeded its service level. True, and hard to act on, because it does not say who was owed anything or who is now late for somebody else.
Read the same delay against a network of commitments and it says something a person can do something about: Sofia asked Aran on the fourth, the answer was due on the sixth, and Tomas has promised Priya something that cannot now be true. Same delay, same data. The difference is that the second one has two names in it and a broken promise at the end, and it goes to the person who is going to have to renegotiate rather than to whoever owns the queue.
To be exact about what this tool does and does not do: it does not watch your work. Nothing you draw here leaves the browser and no system is monitored, because it is an instrument for designing coordination rather than running it. What it produces is the account of what was supposed to happen — who was meant to ask whom, what would count as done, and by when — which is the thing any alert has to be read against before it means anything. Logs are about to be abundant. That account is what stays scarce.
Use both, for the things each is for
The honest recommendation is not to throw anything away.
Model the coordination as commitments while you are deciding how the work should go — who asks whom, what would count as done, where somebody is allowed to refuse and what happens if they do. That is a design conversation and it takes an hour.
Then implement the mechanical parts however you like, in BPMN on an engine, in code, in whatever the platform team has standardised on. Those are different jobs. One is about what the machines do. The other is about what the people owe each other, which is the part that will still be true after you replace the platform.
If you want to see the difference rather than read about it, the difference is a run: draw the handover everybody complains about and watch it act by act, with a work inbox beside it saying whose turn it is. The complaint is usually that something is slow. What the run tends to show is that something is never closed, or that two people each believe the other one is waiting.