BPMN exclusive vs parallel gateways: a token-by-token worked example

Use an exclusive gateway (XOR) when one process token must choose exactly one eligible path. Use a parallel gateway (AND) when every outgoing path must start, or when the process must wait for every incoming parallel path to finish. In the worked purchase-review process below, the first XOR sends an incomplete request back and lets only a complete request continue. The AND pair then changes the token count from 1 to 2 and back to 1. A final XOR produces exactly one disposition.

Scope: gateway semantics, not workflow deployment

BPMN uses tokens as a conceptual way to explain process flow. A token arriving at a diverging XOR leaves on one outgoing sequence flow. A token arriving at a diverging AND causes a token to leave on every outgoing sequence flow. At a converging AND, continuation waits until the required incoming flows have supplied their tokens.

This note applies those semantics to a static model. It does not claim that Schematex executes BPMN, exports BPMN XML, evaluates conditions, or proves that a vendor engine will deploy the model. The Schematex BPMN syntax reference describes a rendered subset and explicitly identifies those product boundaries. Before deployment, translate the approved model into the target engine's supported BPMN profile and test its condition language, variable types, retries, incidents, and transaction behavior.

The standards lineage also needs precision. OMG BPMN 2.0.2 was published in January 2014. ISO lists ISO/IEC 19510:2013 Edition 1 as current after confirmation in 2022, but identifies that ISO publication as identical to OMG BPMN 2.0.1. This example uses the OMG 2.0.2 gateway semantics; the ISO page establishes the continuing international-standard status, not a claim that the edition numbers are identical.

Inputs and assumptions

The fictional process starts when an employee submits a purchase request. The process uses these declared facts:

Input or rule	Worked value	Modeling consequence
complete	true or false	One XOR route is selected; missing data uses the default route
Budget check required	always	One branch must start after the AND split
Policy review required	always	The second branch must start after the same split
budget_ok	Boolean result	Read only after the budget task finishes
policy_ok	Boolean result	Read only after the policy task finishes
Approval rule	both_ok = budget_ok AND policy_ok	One final XOR route is selected

Both reviews are required for every complete request, so an AND split is appropriate. They may complete in either order. “Concurrent” here means the process has two independently active paths; it does not guarantee two operating-system threads, two workers, or simultaneous wall-clock execution. Camunda's current parallel-gateway manual makes the same implementation boundary explicit for its engine.

The two XOR decisions are total only because each has one conditional route and one default route. Without the default, complete = false or a non-matching approval state could strand an executable process, depending on the engine.

Reproducible Schematex source

bpmn
direction: LR
title: "Purchase request review"

pool "Company" {
  lane "Requester" {
    A: start "Request submitted"
    B: task user "Check required fields"
    G0: gateway xor "Complete?"
    R: end "Return for correction"
  }
  lane "Review team" {
    G1: gateway and "Start both checks"
    C: task service "Check budget"
    D: task user "Review policy"
    G2: gateway and "Both checks complete"
    G3: gateway xor "Approve?"
    E: task send "Notify approval"
    F: task send "Notify rejection"
    EA: end "Approved"
    ER: end "Rejected"
  }
}

flows
A --> B
B --> G0
G0 --? "complete" --> G1
G0 --* "missing data" --> R
G1 --> C
G1 --> D
C --> G2
D --> G2
G2 --> G3
G3 --? "both_ok" --> E
G3 --* "otherwise" --> F
E --> EA
F --> ER

This source validates in Schematex 1.0.9. The gateway xor declarations render the X marker; gateway and renders the plus marker. Conditional flows use --?, while --* marks the single default route permitted from a gateway. The source is deterministic notation, not executable condition syntax.

Trace the tokens for an approved request

Assume complete = true, budget_ok = true, and policy_ok = true. Give the arriving process token the identifier t0 only to make the trace auditable:

Step	Element reached	Tokens before	Tokens after	Check
1	G0 completeness XOR	1	1	Only the complete sequence flow is taken
2	G1 parallel split	1	2	One token enters C; one enters D
3	C finishes first	2	1 active + 1 waiting	The join must not continue yet
4	D finishes	1 active + 1 waiting	1	G2 now releases one continuation token
5	G3 approval XOR	1	1	Only the approval route is taken
6	EA approved end	1	0	This process path is complete

The invariant is 1 → 2 → 1, not 1 → 2 → 2. The AND join is synchronization: it consumes the arrivals from the two modeled parallel paths and releases one continuation. If policy finishes before budget, rows 3 and 4 reverse but the result does not change.

Now change only policy_ok to false. Rows 1 through 4 remain the same because both checks are mandatory. At G3, the approval condition is false, so the default otherwise flow sends the single token through rejection. XOR changes destination, not token count.

Finally, set complete = false. G0 sends the token directly to R. No token reaches G1, so neither review starts. That is the operational difference between the first XOR and the later AND: the XOR suppresses ineligible work; the AND initiates all required work.

The gateway crosswalk reviewers need

Review question	Exclusive gateway (XOR)	Parallel gateway (AND)
Diverging behavior	Select exactly one outgoing path	Activate every outgoing path
Are outgoing conditions meaningful?	Yes; define disjoint choices and a default	No; the gateway does not choose by condition
Converging behavior	Merge alternatives without waiting for other alternatives	Wait for all modeled incoming parallel paths
Token count in this example	1 → 1	split 1 → 2; join 2 → 1
Typical review error	Overlapping conditions or missing default	Missing branch, missing join, or a join waiting for a path that never starts

An XOR merge is not a synchronization shortcut. OMG states that each token arriving at a converging exclusive gateway proceeds without synchronization. If concurrent budget and policy paths were merged with XOR, each arrival could continue independently and the notification stage could run twice. Conversely, replacing the completeness XOR with an AND would start both “continue” and “return” paths, contradicting the business rule.

Checks before accepting the model

1. Every XOR decision is total. Its conditions are mutually exclusive for the intended data domain, and a marked default handles every remaining value.
2. Every AND branch is unconditional and required. If a branch is optional, an unconditional AND split is the wrong statement; examine an inclusive gateway or an earlier explicit decision instead.
3. The join matches the split. Every path started by G1 can reach G2 exactly once in the normal model. A cancellation, loop, or early end would require a different synchronization design.
4. No work happens twice. Downstream notification has one incoming continuation from the AND join, not independent incoming flows from both review tasks.
5. Conditions use available data. The final decision occurs after both results exist. Moving it before G2 would create a race or read an unset result in an executable workflow.
6. Labels describe business meaning. “Complete,” “missing data,” and the approval expression can be mapped to test cases; “yes” and “no” alone are easier to invert during maintenance.

Failure modes and review boundary

The diagram deliberately excludes timeouts, review reassignment, cancellation, compensation, exception handling, repeated revisions, and service-task retries. Schematex 1.0.9 also does not model boundary events or export BPMN 2.0 XML. Do not insert a free-floating timer and claim it is equivalent to an interrupting boundary timer; that changes the modeled semantics.

A visual review cannot prove that an engine's expressions are type-safe, that two conditions cannot both become true, or that side effects are idempotent after retries. Camunda 8.9, for example, evaluates XOR conditions in model order and uses the first match; that vendor behavior is useful deployment evidence but should not be generalized to every engine. Test the actual engine with at least the three input rows used here: incomplete, complete-and-approved, and complete-but-rejected.

The concrete next step is to copy the source into the Schematex playground, change one gateway at a time, and repeat the token ledger. If the written count and the intended business rule disagree, fix the process model before adding engine-specific properties. The rendered diagram is a drafting and review aid; process owners and implementation engineers remain responsible for approving and testing the executable workflow.