Direct Answer
BPMN 2.0 defines five gateway types, each with a different routing logic. Exclusive (XOR): one outgoing path fires, based on a condition: used for simple branching decisions. Inclusive (OR): one or more outgoing paths fire: used when multiple parallel outcomes are possible but not all are guaranteed. Parallel (AND): all outgoing paths fire simultaneously: used when work genuinely runs in parallel. Event-Based: the next path is determined by whichever event occurs first: used for wait states where the response depends on external triggers. Complex: advanced conditional logic using a custom expression: rarely needed. Using an Inclusive gateway when you mean Exclusive is the most common error: it implies that multiple paths can run simultaneously when the intent is that only one should. In Sparx EA, each gateway renders with a distinct symbol inside the diamond shape: X (Exclusive), O (Inclusive), + (Parallel), pentagon (Event-Based).
Why Gateway Choice Matters
A process diagram with the wrong gateway type is a specification error, not just a cosmetic one. BPMN is increasingly used as an executable process specification: fed into workflow engines (Camunda, Zeebe, jBPM, Flowable) or used to configure RPA tools. When the gateway type is wrong, the executing engine behaves differently from the intent.
Even for non-executable process models, the wrong gateway type misleads analysts. A process stakeholder reading an Inclusive gateway expects that multiple paths might run simultaneously. If the analyst actually meant only one path runs, the model has communicated something false.
Precise gateway choice is the discipline that separates professional process modeling from diagram decoration.
Gateway 1: Exclusive (XOR): One Path, One Condition
Symbol: Diamond with an X inside, or a plain diamond with no marker.
What it means: Exactly one outgoing sequence flow is activated, based on evaluation of mutually exclusive conditions. The conditions on outgoing sequence flows must be exhaustive (every possible situation is covered) and mutually exclusive (no situation satisfies more than one condition).
The default condition. Every XOR gateway should have one outgoing flow marked as the Default flow: the path taken if no other condition evaluates to true. In Sparx EA, set the default flow by right-clicking the sequence flow → Advanced → Set as Default. The default flow renders with a small diagonal slash through the sequence flow arrow.
When to use:
- “If credit score > 700, approve; otherwise, decline.”
- “If document type is Invoice, route to accounts payable; if Purchase Order, route to procurement.”
- “If claim value < $10,000, auto-approve; otherwise, send for manual review."
When not to use:
- When multiple conditions might be true simultaneously. Use Inclusive (OR) instead.
- When all downstream work always runs. Use Parallel (AND) instead.
In Sparx EA: Drag an Exclusive Gateway from the BPMN 2.0 toolbox. Label each outgoing sequence flow with its condition (right-click → Properties → Condition Expression or enter as a label directly on the flow).
Gateway 2: Inclusive (OR): One or More Paths
Symbol: Diamond with a circle (O) inside.
What it means: One or more outgoing sequence flows are activated, based on conditions. Each condition is evaluated independently: multiple conditions can be true simultaneously, activating multiple parallel paths.
The key distinction from XOR: with Inclusive, if three conditions are true, three paths run. With Exclusive, only one path runs regardless.
The synchronizing join. When Inclusive gateway is used to split, the corresponding join (merging) must also be an Inclusive gateway. The join waits for all activated paths to complete before continuing: not for all paths, just the ones that were actually activated. This “activated path tracking” is what makes the Inclusive gateway semantically complex and why it should be used only when genuinely needed.
When to use:
- “Trigger notification to HR, Finance, and/or Legal depending on which policy changes apply.”
- “Based on the customer profile, apply one or more of: loyalty discount, bulk discount, first-order discount.”
- “Run whichever of the following checks are relevant to this application type: credit check, identity verification, address verification.”
When not to use:
- When exactly one path runs. Use Exclusive (XOR).
- When all paths always run. Use Parallel (AND).
- When the downstream merge logic is unclear. Inclusive gateway joins are the most common source of workflow engine errors: be certain.
In Sparx EA: Drag an Inclusive Gateway from the BPMN 2.0 toolbox. Label each outgoing sequence flow with its condition.
Gateway 3: Parallel (AND): All Paths Simultaneously
Symbol: Diamond with a plus sign (+) inside.
What it means: All outgoing sequence flows are activated simultaneously, with no conditions. The process splits into parallel branches, all of which execute.
The corresponding join (Parallel merge) waits for all branches to complete before the process continues. There are no conditions to evaluate: every branch runs, full stop.
When to use:
- “Send acknowledgement to customer AND update inventory AND log order in ERP simultaneously.”
- “Run background check, reference check, and technical assessment in parallel.”
- “Notify all three departments simultaneously.”
Common misuse: using Parallel gateway when the branches are not genuinely independent. If Branch A produces a document that Branch B needs, the branches are not truly parallel: there is a dependency that the Parallel gateway model hides.
In Sparx EA: Drag a Parallel Gateway from the BPMN 2.0 toolbox. Connect all parallel tasks as outgoing flows from the gateway. Connect all parallel branch endings to a Parallel merge gateway.
Gateway 4: Event-Based: First Event Wins
Symbol: Diamond with a pentagon (regular five-sided polygon) inside, often with a double-line circle.
What it means: The process reaches a wait state and the next step is determined by whichever event occurs first. All downstream paths are conditioned on receiving an event: a message, a timer expiry, a signal, or a condition. The first event to fire activates its path; all other paths are canceled.
This is the BPMN mechanism for race conditions and timeout patterns. “Wait for either a customer response OR a 48-hour timeout: whichever comes first.”
The elements after an Event-Based gateway must be event catchers: Intermediate Catch Events (Message, Timer, Signal, Conditional, Error). They cannot be tasks or other gateways. This is a BPMN 2.0 rule.
When to use:
- “After sending quote, wait for customer acceptance OR 5-day timeout.”
- “After placing order with supplier, wait for delivery confirmation OR cancellation notice.”
- “After submitting application, wait for approval decision OR escalation trigger.”
In Sparx EA: Drag an Event-Based Gateway. Connect outgoing sequence flows to Intermediate Catch Event elements, each typed appropriately (Timer, Message, etc.). Label each catch event clearly.
Gateway 5: Complex: Custom Conditional Logic
Symbol: Diamond with an asterisk (*) inside.
What it means: The gateway has custom activation logic that cannot be expressed with the other four types. The activation condition is documented as a text expression on the gateway element. Some paths may or may not activate based on complex multi-variable logic.
When to use: Rarely. The Complex gateway is a catch-all for genuinely complex routing that cannot be modelled with the other four types. Before using Complex, question whether the process can be refactored to use standard gateway types. A need for Complex gateway often signals a process that needs re-design rather than a modeling problem.
In Sparx EA: Drag a Complex Gateway. Document the activation logic in the element’s condition expression or notes field.
Decision Table: Gateway Quick Reference
| If the process needs to… | Use… gateway |
|---|---|
| Choose one path from several conditions | Exclusive (XOR) |
| Activate one or more paths based on independent conditions | Inclusive (OR) |
| Run all paths simultaneously without conditions | Parallel (AND) |
| Wait for whichever event fires first | Event-Based |
| Express complex multi-variable routing logic | Complex |
Conditions on Sequence Flows in Sparx EA
For Exclusive and Inclusive gateways, every outgoing sequence flow (except the default) must have a condition expression.
In Sparx EA:
- Right-click the outgoing sequence flow
- Select Properties
- In the Condition Expression field, enter the condition:
creditscore > 700,documenttype == 'Invoice',claim_value < 10000 - The condition expression renders as a label on the flow in the diagram
Use a consistent notation for conditions across all processes in your repository: natural language ("Credit score above threshold") or formal expression (creditScore > threshold): and document the convention in your modeling standards.
Frequently Asked Questions
Q: What happens if conditions on XOR gateway flows are not mutually exclusive? A: In a process model (non-executable), it creates ambiguity: the reader cannot determine which path the process takes when multiple conditions are true. In an executable process (workflow engine), behavior depends on the engine: some engines fire the first matching condition in sequence; others throw a validation error. Always design XOR gateway conditions to be explicitly mutually exclusive, with a default flow for any uncovered case.
Q: Can a gateway have only one outgoing flow? A: A gateway with one outgoing flow is a modeling error: gateways are used for branching and merging. A gateway with one outgoing flow and one incoming flow does nothing. Remove it. The only exception is a gateway that will be completed later (a work-in-progress model), but it should be flagged as incomplete.
Q: How do I model a loop back in BPMN? A: Use a sequence flow that connects an activity or gateway output back to an earlier point in the process. Combine with an Exclusive gateway at the loop-back point: one outgoing flow continues forward (exit condition met); one flows back to the repeated activity (exit condition not met). This is the standard BPMN loop pattern. Do not confuse this with the Loop marker on a task (which marks the task itself as iterating internally).
Q: What is the difference between an Event-Based gateway and a conditional Exclusive gateway? A: An Exclusive gateway evaluates conditions immediately when the token arrives: the conditions are data-based or expression-based. An Event-Based gateway waits: the process is paused and the token activates whichever outgoing path receives the event first. Use Exclusive for data-driven decisions that can be made immediately; use Event-Based for external trigger waits where the process must pause for an external signal.
Q: How do I show that a process can follow multiple paths based on different user roles in BPMN? A: If only one role handles the activity at a time (one path runs), use an Exclusive gateway with conditions based on the role. If the process is designed so that different roles perform parallel activities simultaneously, use a Parallel gateway. Role-based routing is typically Exclusive: one approver handles the document, not all approvers simultaneously. Use pools and lanes to show which role performs which activity, and gateways to route between them.
Q: Does Sparx EA validate gateway conditions automatically? A: Sparx EA's BPMN 2.0 validation checks structural rules: that Event-Based gateway outgoing flows connect to event catchers, for example. It does not validate the logical correctness of condition expressions (whether conditions are mutually exclusive). That validation is the modeler's responsibility. Run the BPMN validation (Tools → Model Validation → BPMN 2.0 profile rules) to catch structural errors, but plan and verify condition logic manually.
Next Step
If your organization's process models have gateway inconsistencies: wrong types, missing conditions, ambiguous joins: the Amplify engagement includes BPMN standards development, team training, and model quality review. Consistent gateway usage is a modeling standards problem; Amplify delivers the standards and the governance to enforce them.
