BPMN gateways
Rhombi, and the marker inside each one. A gateway never does work - it only decides how many of the outgoing paths carry a token, which turns out to be the thing every argument about a process is really about.
9 min readBPMN 2.03 of 3
01A gateway is a rule about tokens
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.
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.
02The five kinds
| Element | Notation | What it means |
|---|---|---|
| Exclusive (XOR) | rhombus with an X, or empty | Exactly one outgoing path is taken. The conditions are evaluated in order and the first true one wins. The default gateway and the one to reach for first. |
| Parallel (AND) | rhombus with a + | Every outgoing path is taken, with no conditions at all. As a merge, it waits for every incoming path before continuing. |
| Inclusive (OR) | rhombus with a circle | Every path whose condition is true is taken - one, several, or all. As a merge it waits for exactly the paths that were activated, which is cleverer than it sounds and is where deadlocks come from. |
| Event-based | pentagon in a double ring | Does not decide - waits. The path whose event fires first is taken and the others are discarded. |
| Complex | rhombus with an asterisk | An escape hatch for rules the other four cannot express - "continue when three of the five approvals are in". Rare, and usually a sign the process wants restructuring. |
03Splitting and merging
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.
| Element | Notation | What it means |
|---|---|---|
| Exclusive merge | several in, one out | Passes each token straight through as it arrives. It does not wait, because only one branch was ever taken. |
| Parallel merge | several in, one out | Waits for every incoming path, then emits one token. This is the one that blocks, and it should be blocking on purpose. |
| Inclusive merge | several in, one out | Waits for exactly the branches that were activated upstream. Requires the engine to reason about the whole process, and is the construct most likely to behave differently between tools. |
| Mixed gateway | several in, several out | Legal. Unreadable. Split with one gateway and merge with another, and the diagram will tell you what it is doing. |
04The event-based gateway
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.
05Conditions and default flows
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.
Reach for it when
- Exclusive when precisely one path applies - which is most of the time
- Parallel when both paths must run and neither depends on the other
- Event-based when the process is waiting and something external decides
- A default flow on every branching exclusive or inclusive gateway
Reach for something else when
- Inclusive when exclusive would do - it costs clarity and adds a deadlock risk
- Complex, almost always - restructure instead
- A gateway immediately after a gateway with nothing between them
- Conditions written as prose paragraphs on the flow label
06Common mistakes
- Parallel split, exclusive merge. The split made two tokens; the exclusive merge passes both through, and everything after it happens twice.
- Inclusive split, parallel merge. The deadlock above. Match your gateways.
- Work inside the gateway.A rhombus labelled "Validate and route" is a task and a gateway wearing one outline. Split them.
- Unlabelled branches. Two lines leaving a rhombus with nothing written on them make the reader guess, and half of them will guess wrong.
- No default flow. The one input nobody thought about arrives and the token has nowhere to go.
- 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.
In one line each
- 01A gateway changes how many tokens exist and does no work of its own.
- 02Exclusive picks one path, parallel takes all of them, inclusive takes the true ones.
- 03The event-based gateway does not decide - it races catching events.
- 04Match every split with a merge of the same kind.
- 05Inclusive split into a parallel merge is the classic deadlock.
- 06Name the gateway as a question and label every branch with an answer.