# Lack of Synchronization

**In short:** A lack of synchronization happens when parallel branches are merged by an exclusive (XOR) join. Nothing waits for the other branches, so the work after the merge runs once per branch instead of once.

## Explanation

A process model can split work into parallel branches. A parallel (AND) gateway does this: it takes all outgoing flows at once. Each branch carries its own token, a marker that shows where the process instance currently is.

A lack of synchronization is a modeling error. It appears when those parallel branches come back together at an exclusive (XOR) gateway instead of a parallel one.

An exclusive join does not synchronize. Each token that arrives simply continues on its own. Camunda describes this as pass-through behavior: the gateway does not merge concurrent flows the way a parallel gateway does.

The result is that every task after the merge can run once for each arriving token. Two branches mean two runs of the downstream work.

**The fix** is to join the branches with a parallel (AND) gateway. It waits until all required incoming flows have delivered their tokens. It then consumes those arrivals and releases one continuation. The downstream tasks then run once.

To spot the error, look at each place where parallel branches merge. Check which type of gateway does the merging.

For related gateway-mismatch patterns, see BPMN Gateway Mismatch Antipatterns. For the gateways themselves, see BPMN Gateway.

## Example

An order process splits after payment approval. One branch reserves stock. The other branch prepares the invoice. Both branches then merge at an exclusive gateway, and the next task is "Send confirmation to customer."

The reserve-stock branch finishes and sends a token through the merge. The confirmation goes out. The invoice branch finishes later and sends its own token. The confirmation goes out again.

Replacing the exclusive merge with a parallel merge fixes this. The process waits for both branches, then sends one confirmation.

BPMN diagram: [Faulty model: an AND split merged by an XOR join, so 'Send confirmation' runs twice.](https://arc.fuet.ch/diagrams/concepts/modeling-bpmn/lack-of-synchronization-in-process-models/diagram-1.bpmn)

## Checks

- Every place where parallel branches from an AND split come back together uses a parallel (AND) join, not an exclusive (XOR) join.
- No exclusive gateway merges flows that were started concurrently by a parallel gateway.
- Tasks after a merge of parallel branches run only once per process instance.

## Related

- [Deadlock in Process Models](https://arc.fuet.ch/concepts/modeling-bpmn/deadlock-in-process-models.md)
- [BPMN Gateway Mismatch Antipatterns](https://arc.fuet.ch/concepts/modeling-bpmn/antipatterns-for-process-flows.md)
- [BPMN Gateway](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-gateway-semantics.md)
- [Errors in Process Models](https://arc.fuet.ch/concepts/modeling-bpmn/errors-in-process-models.md)
- [Soundness of Process Models](https://arc.fuet.ch/concepts/modeling-bpmn/soundness-of-process-models.md)
- [BPMN Modeling Guidelines](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-modeling-tips.md)

## Sources

- [BPMN exclusive vs parallel gateways: a token-by-token worked example | Schematex Research](https://schematex.js.org/research/bpmn-exclusive-vs-parallel-gateway) — schematex.js.org, accessed 2026-11-09
- [Parallel gateway | Camunda 8 Docs](https://docs.camunda.io/docs/components/modeler/bpmn/parallel-gateways/) — docs.camunda.io, accessed 2026-11-08
- [Exclusive gateway | Camunda 8 Docs](https://docs.camunda.io/docs/components/modeler/bpmn/exclusive-gateways/) — docs.camunda.io, accessed 2026-11-08