BPMN & Business Process Analysis

BPMN Gateways

18 min Lesson 5 of 10

BPMN Gateways

Every real-world business process branches. An order is either approved or rejected. A shipping process waits for both the payment confirmation and the warehouse pick before it proceeds. A loan application may follow a fast-track path, a standard path, or both simultaneously depending on the applicant's score. BPMN models these decision and synchronization points with a single, versatile element: the gateway, drawn as a diamond.

Gateways control how sequence flow splits and joins. A split gateway has one incoming flow and multiple outgoing flows. A join gateway has multiple incoming flows and one outgoing flow. Understanding which gateway type to use is one of the most important modeling skills you will develop as a business analyst.

The Three Core Gateway Types

BPMN 2.0 defines three gateways that cover the vast majority of real process logic:

Exclusive Gateway (XOR) — exactly one outgoing path is taken. Marked with an X inside the diamond.
Parallel Gateway (AND) — all outgoing paths are taken simultaneously. Marked with a + inside the diamond.
Inclusive Gateway (OR) — one or more outgoing paths are taken, depending on conditions. Marked with an O (circle) inside the diamond.

Matching splits with joins: every split gateway should have a corresponding join gateway of the same type. Mixing types (e.g., splitting with a parallel but joining with an exclusive) creates logic errors and confuses both readers and process-engine execution.

Exclusive Gateway (XOR)

The exclusive gateway represents a decision: only one branch is followed. Conditions on the outgoing arrows determine which branch is active. Best practice is to mark one branch as the default (a slash through the arrow) so the process does not deadlock if no condition evaluates to true.

Business scenario — clinic appointment booking: After a patient submits a booking request, the system checks availability. If a slot is available, the booking is confirmed. If no slot is available, the patient is placed on a waiting list. Both outcomes cannot happen at the same time — this is an exclusive gateway.

Exclusive (XOR) gateway: the booking request takes exactly one branch — confirm or waiting list — then both paths converge at the join.

Parallel Gateway (AND)

The parallel gateway activates every outgoing branch at the same time. On the join side it waits for all incoming branches to complete before the process continues. This is the correct element for tasks that must run concurrently — not for optional or conditional work.

Business scenario — online store fulfilment: Once a customer places an order, the store simultaneously notifies the warehouse to pick the items and sends a payment link to the customer. Only after both tasks complete (item picked and payment confirmed) does the courier dispatch step begin.

Parallel (AND) gateway: warehouse notification and payment link run simultaneously; the join waits for both to complete before dispatching the courier.

Deadlock risk: if one branch of a parallel split never completes — for example, the customer never pays — the AND join will wait forever. Always model timeouts or escalation paths for parallel branches that depend on external parties.

Inclusive Gateway (OR)

The inclusive gateway is the most powerful and the most misused gateway in BPMN. It fires all outgoing branches whose conditions are true — meaning one, two, or all branches may be activated. The matching join then waits only for the branches that were actually started.

Business scenario — logistics firm express handling: When a shipment is marked as high-value, the logistics firm may activate special insurance processing, priority routing, and/or fragile packaging, depending on flags set by the customer. Any combination of those three services can run simultaneously, but none are mandatory. The process continues once all activated paths complete.

OR join behaviour is stateful: the inclusive join must "look back" through the process to determine which incoming branches are still active. This makes it significantly more complex for process engines to execute. Use the parallel or exclusive gateway where possible; reach for the inclusive gateway only when multiple conditional paths are genuinely needed.

Splitting vs Joining — A Side-by-Side View

Side-by-side reference: split behaviour (left column) and join behaviour (right column) for each gateway type.

Choosing the Right Gateway

A useful mental test before you place a gateway:

"Is this a decision?" — If exactly one outcome is possible, use XOR.
"Must everything happen?" — If all paths must run in parallel, use AND.
"Could several outcomes be true at once?" — If multiple conditional paths may activate, use OR.

In practice, most business processes use the exclusive and parallel gateways. The inclusive gateway is most common in processes driven by customer-configured options (e.g., a subscription that activates different feature modules) or by risk-scoring systems (e.g., a credit application that triggers various review steps depending on score ranges).

Unnamed exclusive gateways: BPMN allows a plain diamond (no marker) as an implicit exclusive gateway. While valid, this harms readability. Always use the explicit X marker on exclusive gateways, especially in complex models.

Common Mistakes to Avoid

Missing join gateway: splitting with a gateway but not rejoining creates multiple "open" paths that independently reach the end event — valid in BPMN but almost never the intended logic.
AND join after XOR split: the join waits for tokens that never arrive, causing a deadlock in process-engine execution.
No default on XOR: if all conditions evaluate to false, the process token is stuck. Always define a default outgoing flow.
Overusing OR: if conditions are mutually exclusive, an inclusive gateway is unnecessary complexity — use exclusive instead.

Gateways are where business logic lives in a BPMN model. Mastering the three core types allows you to accurately represent any branching, parallel, or conditional business rule, from simple approval decisions to complex multi-service orchestrations. In the next lesson you will learn how to model collaboration across organisational boundaries using pools and lanes.