BPMN gateways

BPMN's execution model is a token moving through the diagram. A gateway is the only thing that changes how many tokens there are: a split can turn one token into several, a merge can turn several back into one. Everything else about gateways follows from that.

A note on the name. The spec says gateway; most people say gate, and search for gates. They are the same thing, and the diamond is the same diamond - but gateway is the word to use in a diagram title, because it is the one every BPMN tool and every reviewer will be reading for.

Two consequences worth holding onto. First, a gateway does no work - it evaluates conditions already computed, and if you want something checked, that is a task before the gateway. Second, a split usually needs a matching merge of the same kind, because whatever created extra tokens has to be undone or they run to the end separately.

The same symbol does both jobs, and which one it is doing depends only on whether it has more outgoing or more incoming flows. A gateway with one in and three out is a split; three in and one out is a merge.

The vocabulary is worth pinning down, because three words get used for the converging case. A converging parallel gateway is a join: it waits for every branch. A converging exclusive gateway is a merge: it waits for nothing and passes each token through. Both are drawn as the same diamond they were when they split, and calling a merge a join is how a diagram ends up claiming work finished that never ran.

Everything in the two sections above is one skill: put a finger on the start event and count. Here is the claim process at the top of this page, walked through one step at a time, with the number of live tokens after each.

1. Claim received fires. One token. It sits on the flow into the first gateway.
2. The parallel split. Two tokens. No conditions are evaluated and nothing is chosen - a parallel split emits one token per outgoing flow, always.
3. Check policy and check fraud run. Still two. They are genuinely concurrent: the diagram makes no claim about which finishes first, and it does not need to.
4. The parallel join. Back to one. Whichever token arrives first waits there. When the second arrives the join consumes both and emits one.
5. Covered? One token, one branch. An exclusive gateway never changes the count - it only changes which flow the token is on.
6. Settle or reject, then the end. Zero. The process instance is finished when the last token is consumed by an end event.

Now break it deliberately, because both of the classic bugs are visible from the count alone.

Make the first gateway exclusive and leave the join parallel. The split now emits one token, so one check runs. The parallel join is still waiting for two. Nothing arrives on the second flow, ever, and the claim sits in the join for the lifetime of the system. That is the deadlock, and it took one changed marker.

Leave the split parallel and make the join exclusive. Two tokens arrive and an exclusive merge waits for nothing, so both pass straight through. Covered? is evaluated twice, the settle task runs twice, and the customer is paid twice. This one is worse than the deadlock, because a deadlock announces itself and a double payment does not.

This is the construct that makes "we wait for the documents, but not forever" expressible in one picture. Every other way of drawing it - a timer boundary event on a wait task, a loop with a condition - either duplicates the timeout logic or hides it.

Two rules go with it. The targets of an event-based gateway must be catching intermediate events or receive tasks, never plain tasks: the gateway is a race between things that arrive, and a task does not arrive. And the branches must be genuinely mutually exclusive in time, which they are automatically - the first to fire discards the rest.

Conditions live on the outgoing sequence flows, not on the gateway. Write them as short expressions a reader can evaluate - amount > 10000, policy status = active - and put them on the line near the gateway rather than near the target.

Exactly one branch of a branching gateway should be the default flow, drawn with a small tick across its tail. It is taken when no other condition holds, and it is what stops a process from stalling at a gateway where the data turned out to be something nobody anticipated.

A model that has learned gateways tends to reach for them for every branch in the world, and the result is a diagram that is 40% rhombus. Four of BPMN's other constructs express a decision better in the cases below, and knowing them is most of the difference between a process model that fits on a page and one that does not.

The test is whether the branch is part of the process or part of a decision. A claim that goes to fast-track or to manual review is process: the two paths look different and a reader needs to see both. Which of nine risk bands a claim falls into is a decision: the paths are identical afterwards, and putting it on the diagram costs eight rhombi to say one thing. See how to draw a BPMN diagram for where that line usually falls in practice.

1. Parallel split, exclusive merge. The split made two tokens; the exclusive merge passes both through, and everything after it happens twice.
2. Inclusive split, parallel merge. The deadlock above. Match your gateways.
3. Work inside the gateway.A rhombus labelled "Validate and route" is a task and a gateway wearing one outline. Split them.
4. Unlabelled branches. Two lines leaving a rhombus with nothing written on them make the reader guess, and half of them will guess wrong.
5. No default flow. The one input nobody thought about arrives and the token has nowhere to go.
6. Plain tasks after an event-based gateway. Not legal, and it usually means an exclusive gateway was meant.

Gateways and eventsare the two halves of BPMN's control flow: gateways decide, events wait and interrupt. A process modelled with gateways alone tends to grow long chains of polling; one that uses boundary events where it should stays much closer to what actually happens.