Gateway (BPMN)
A BPMN gateway is a diamond-shaped element that controls how a process branches or merges. The symbol inside the diamond tells you which routing rule applies: exclusive (×), parallel (+), inclusive (O), or event-based (pentagon). A gateway does no work itself — it only decides which path (or paths) the flow takes next.
In practice, most real-world BPMN diagrams only need two kinds of gateway: exclusive, for either/or decisions, and parallel, for running two or more branches at the same time. Inclusive and event-based gateways show up mainly in longer-running processes where the path depends on independent conditions or on whichever event triggers first.
Gateway example: high-value claim handling
A short BPMN flow that uses two gateway types together. The exclusive gateway routes on whether the claim is high-value. If it is, a parallel gateway fans out into fraud check and manager review, which must both finish before the claim is paid out.
BPMN gateways — exclusive and parallel, side by side
A small BPMN 2.0 flow that shows two gateway types in the same diagram: an exclusive gateway (diamond with an "×") that routes the process down one of two paths, and a parallel gateway (diamond with a "+") that splits the flow into two simultaneous paths and then joins them back together.
- A claim arrives at the start event.
- Assess the claim to collect the facts needed to route it.
- An exclusive gateway asks "Is the claim high-value?" — exactly one outgoing path is taken.
- If high-value, a parallel gateway fans out: Fraud check and Manager review run at the same time.
- A second parallel gateway waits for both checks to finish before carrying on.
- If not high-value, the claim is auto-approved instead.
- Either path converges on the Pay out task, then the process ends.
The four gateway types
Four markers cover almost every branching pattern you will meet.
Exclusive gateway (×)
Picks exactly one outgoing path. Use it for either/or decisions: approved vs declined, high-value vs low-value, customer vs enterprise. One condition, one path, simple to reason about — this is the gateway you reach for most often.
Parallel gateway (+)
Splits the flow into two or more simultaneous paths, and when used as a join it waits for every incoming path to complete before moving on. Use it when several activities must run at the same time — for example, a credit check and a fraud check before a loan is paid out.
Inclusive gateway (O)
Each outgoing path has its own independent condition, and any combination of those paths might apply. Use it sparingly — inclusive logic is easy to write and hard to read. A common honest use case: “send an email, send a letter, log an audit entry” where each action fires based on its own flag.
Event-based gateway (pentagon inside the diamond)
Routes on whichever intermediate event fires first. Typical pattern: the process waits for a customer reply, a seven-day timeout, or a cancellation message — whichever happens first wins and the others are ignored. Shows up almost exclusively in long-running processes.
How to pick the right gateway
1. Decide whether paths are mutually exclusive
If only one of the outgoing paths can be taken, start with an exclusive gateway. Common examples: approved vs declined, customer vs enterprise tier, high-value vs low-value claim.
2. Check whether paths must run at the same time
If several things need to happen in parallel and the process cannot move on until every one of them finishes, use a parallel gateway to split and a matching parallel gateway to join.
3. Check whether path selection is independent
If each outgoing path has its own independent condition and any combination might apply (for example, send an email AND send a letter AND log an audit entry based on three separate flags), use an inclusive gateway.
4. Check whether the process is waiting on an event
If the flow needs to take whichever of several paths triggers first — say, a customer reply OR a seven-day timeout OR a cancellation message — use an event-based gateway with the relevant intermediate events on each outgoing arm.
Gateway vs plain flowchart decision point
A flowchart diamond is informal — the reader guesses what “decision” means in context. A BPMN gateway is strict. The marker inside the diamond disambiguates the routing rule, and any conformant BPMN tool or process engine will respect that rule in exactly the same way. That is the whole point of a standard notation: the same diagram reads the same everywhere.
BPMN gateway FAQ
What is a gateway in BPMN?
A gateway is a diamond-shaped BPMN element that controls branching and merging in a process. It does not do any work itself — it only decides which outgoing path (or paths) the flow takes. The marker inside the diamond tells you which routing rule applies.
What are the four main BPMN gateway types?
Exclusive (×) picks exactly one outgoing path based on a condition. Parallel (+) activates all outgoing paths simultaneously and then waits for every path to finish before continuing. Inclusive (O) picks one or more outgoing paths based on independent conditions. Event-based (pentagon inside the diamond) routes to whichever intermediate event fires first — typically used when a process is waiting for a message, a timer, or a cancellation.
When do I use an exclusive gateway vs a parallel gateway?
Use an exclusive gateway when the process must pick one of several mutually-exclusive paths — a yes/no decision, an approved/declined branch, a segment-based route. Use a parallel gateway when several things must happen at the same time and the process cannot move on until they all finish — for example, a credit check and a fraud check running in parallel before a loan is paid out.
Is a BPMN gateway the same as a flowchart decision diamond?
Visually yes — they are both diamonds — but the BPMN gateway carries stricter semantics. A flowchart diamond is informal: the reader infers what "decision" means. A BPMN gateway has a fixed marker (×, +, O, pentagon) that disambiguates the routing rule and is respected by process engines that execute the diagram.
Do I need a joining gateway after a splitting gateway?
For a parallel split, yes — you need a matching parallel join to reliably wait for every branch before carrying on. For an exclusive split, a joining gateway is usually a readability preference rather than a correctness requirement, because only one branch is active at a time. The convention in most BPMN tool chains is to always pair a splitting gateway with its join for clarity.
Let the AI pick the gateway
Describe a process that branches — exclusive decisions, parallel work, or waiting on an event — and BA Copilot's AI will place the right gateway type for you. Refine it in the drag-and-drop editor.