BPMN
BPMN gateways explained: types, symbols and examples
Robbert Schuurmans
A BPMN gateway is the diamond that controls where a process goes next. It splits one path into several, or joins several paths back into one. The marker inside the diamond tells you the rule: exclusive (X) picks one path, parallel (+) takes all of them, inclusive (O) takes one or more, and event-based lets the first event decide.
Without gateways, a BPMN diagram is a straight line. With the wrong gateway, it is a process that stalls or runs twice. Below you find every gateway type with a diagram, how splitting and joining work, and the mistakes that show up most in real models.
What is a gateway in BPMN?
A gateway is a diamond on the sequence flow. It does one of two things:
Split: one incoming path, several outgoing paths.
Join (merge): several incoming paths, one outgoing path.
The same symbol is used for both. Whether a gateway splits or joins follows from how many flows go in and out.
One point that trips up many beginners: a gateway does not do any work and does not make a decision by itself. It routes based on data or an event that already exists. If someone has to judge a request, model that as a task first ("Review request"), and only then the gateway that routes on the outcome.
The BPMN gateway types at a glance
Exclusive gateway (XOR): empty diamond or a diamond with an X. Exactly one path.
Parallel gateway (AND): diamond with a plus. All paths at the same time.
Inclusive gateway (OR): diamond with a circle. One or more paths.
Event-based gateway: diamond with a pentagon in a double circle. The first event to happen wins.
Complex gateway: diamond with an asterisk. A custom rule, rarely needed.
Exclusive gateway (XOR): exactly one path
The exclusive gateway checks conditions and follows exactly one outgoing path. It is by far the most used gateway, and the one behind every "yes or no" question in a process.
An exclusive gateway routes an approved invoice to payment and every other invoice back to the sender. The slash marks the default flow.
Two things make an exclusive gateway reliable. The conditions must not overlap, so that only one can be true. And one outgoing flow should be the default flow, marked with a small slash. The default is taken when no condition matches, which stops a process from stalling on a case nobody thought of.
Parallel gateway (AND): all paths at once
The parallel gateway has no conditions. When the process reaches it, every outgoing path starts at the same time.
A parallel split starts packing and invoicing together. The parallel join waits until both are done.
The second parallel gateway is just as important as the first. As a join, it waits until all incoming paths have arrived before the process continues. That is how you say in BPMN: "ship the order only when the goods are packed and the invoice is sent."
Inclusive gateway (OR): one or more paths
The inclusive gateway evaluates every condition and follows each path whose condition is true. That can be one path or several.
An inclusive gateway starts a vehicle assessment, an injury assessment, or both, depending on the claim.
As a join, the inclusive gateway waits for the paths that were actually started, not for all of them. In the example, a claim with only vehicle damage continues as soon as the vehicle assessment is done. In a real claims process you would also give the inclusive split a default flow, for claims where neither condition is true. The figure leaves it out to stay readable.
Event-based gateway: the first event wins
The event-based gateway does not look at data. It waits, and the first event that happens decides the route. The other paths are then dropped.
After the quote is sent, either the acceptance arrives or the seven-day timer runs out. Whichever comes first decides.
Each outgoing path of an event-based gateway must lead straight to a catching event (a message, timer or signal) or a receive task. That is exactly what makes it the right choice for "wait for an answer, but not forever".
Complex gateway: only when nothing else fits
The complex gateway, a diamond with an asterisk, lets you define your own rule. A typical example is a join that continues as soon as two out of three reviewers have responded. It is valid BPMN, but readers rarely understand it without explanation. Use it only when a combination of the other gateways cannot express the rule.
Split and join: closing what you open
Most gateway errors are not in the split but in the join. The rule of thumb: join with the same type you split with.
Parallel split, parallel join. The join waits for every branch.
Inclusive split, inclusive join. The join waits for the branches that were started.
Exclusive split, exclusive merge, or simply let the flows run into the next task.
Mixing them breaks the logic in ways that are easy to miss on paper:
A parallel split joined by an exclusive gateway lets each branch through separately. Everything after the merge happens twice.
An exclusive split joined by a parallel gateway waits for a branch that was never started. The process stops there for good.
Inclusive vs exclusive gateway: which one?
Ask one question: can more than one condition be true at the same time?
No, the options exclude each other (approved or rejected, below or above a limit): use an exclusive gateway.
Yes, several can apply together (vehicle damage and injury, email and text message): use an inclusive gateway.
All of them always apply, without a condition: that is a parallel gateway.
Five common gateway mistakes
No default flow on an exclusive or inclusive split, so an unexpected case has nowhere to go.
Overlapping conditions on an exclusive gateway, such as "amount ≤ 1,000" and "amount ≥ 1,000".
The wrong join type, with the double execution or deadlock described above.
Putting the decision in the gateway instead of in a task before it. "Is the request complete?" is a gateway label; checking the request is work, and work is a task.
Long questions as labels. Keep gateway labels short ("Approved?") and name the outgoing flows ("Yes", "No"), so the diagram stays readable on a screen or a phone.
Gateways without drawing them yourself
Picking the right gateway is where most hand-drawn models go wrong, and the errors only show up when someone tries to run or automate the process. ModelMatic turns an interview, a document or a recording into a BPMN 2.0 model with the gateways already in place, and flags the decisions that are still unclear so you can check them with the process owner.
New to the notation? Start with what BPMN is and the overview of BPMN symbols, or see complete processes in the BPMN examples.
BPMN is maintained by the Object Management Group and standardised as ISO/IEC 19510. The full definition of every gateway is in the OMG BPMN 2.0 specification.
