---
title: Token Semantics (BPMN Process Execution)
type: concept
tags: [bpm, bpmn, semantics, tokens, petri-nets, modelling, runtime]
sources:
  - "[[sources/2018-dumas-fundamentals-of-bpm]]"
  - "[[sources/1998-vanderaalst-verification-of-workflow-nets]]"
created: 2026-05-04
updated: 2026-05-04
---

# Token Semantics (BPMN)

The execution semantics of a BPMN process model are defined by **tokens** — abstract markers that represent the progress of a process instance. Tokens are not visible at runtime; they are a *semantic device* for reasoning about model behaviour.

## Core mechanics

From [[sources/2018-dumas-fundamentals-of-bpm]] §3.1 and §3.2:

- A **token** is created at a **start event** when a new process instance begins.
- The token **flows** through the model along sequence flows.
- The token is **destroyed** at an **end event**.
- Activities **consume** an incoming token, perform their work, and **produce** an outgoing token.
- Multiple instances of the same process model run independently — each has its own set of tokens (often visualised by colour).

The state (or *marking*) of a process instance at any point is the distribution of its tokens across the model's elements. This is exactly the [[concepts/workflow-net|Petri-net marking]] concept, mapped onto BPMN.

## Gateway token semantics

| Gateway | Split (1 in, N out) | Join (N in, 1 out) |
|---|---|---|
| **XOR** ◇X | Routes the incoming token to exactly **one** outgoing branch (based on conditions) | **Pass-through**: every arriving token is forwarded immediately to output |
| **AND** ◇+ | Generates **N tokens** — one for each outgoing branch | **Synchronises**: waits for one token on each input, then merges them into a single output token |
| **OR** ◇O | Generates **k tokens** (1 ≤ k ≤ N), one for each branch whose condition is true | **Synchronising merge**: waits for all *active* branches to complete, then merges their tokens into one |
| **Event-based** ◇⬠ | (Implicit) — the *first event* to arrive selects which branch fires | (rare) |

The OR-join's "active branch" semantics is the most subtle: it waits for tokens only on incoming branches that *will* eventually deliver one. This requires global reasoning ([[sources/2018-dumas-fundamentals-of-bpm]] §3.2.3) and is the reason [[concepts/7pmg]] G5 cautions against OR usage.

## Implicit termination

BPMN uses **implicit termination semantics**:

> *A process instance completes only when each token flowing in the model reaches an end event.*

Consequences:
- A model with multiple end events can have a single instance reach **one** end event with one token while another token is still flowing — the instance does not complete until *all* its tokens reach an end event.
- This is why [[concepts/soundness]] clause (2) in Dumas's formulation says "*each token must be in a different end event*" at completion (multi-end variant).

A **terminate end event** (⊗) overrides this — firing one terminate end event force-completes the entire instance, discarding any other tokens. Use sparingly: it can hide modelling errors that would otherwise manifest as anomalies.

## Multiple start events

BPMN also allows multiple start events, each capturing a different trigger. An instance is initiated by **whichever start event fires first**; only one start event creates the instance's initial token.

This is distinct from process *variants* — a single process can have multiple legitimate triggers (e.g., new purchase order *or* revised purchase order).

## Why token semantics matter for the modeller

Three practical implications:

1. **Anomaly reasoning**: [[concepts/deadlock]], [[concepts/livelock]], [[concepts/lack-of-synchronization]], [[concepts/dead-activity]] are all defined in terms of token movement. Reasoning at the token level is the right mental model when debugging unsoundness.

2. **Gateway selection**: choosing XOR vs AND vs OR is choosing token-multiplication semantics. *"Do I want one token routed, or N tokens spawned, or k≤N tokens spawned?"*

3. **Parallel-branch correctness**: AND-split + AND-join must be balanced — every token created at the split must arrive at the join. Bypass paths break this and cause [[concepts/deadlock]] or [[concepts/lack-of-synchronization]].

## Token-flow visualisation tools

- **bpmn-js-token-simulation** (open-source, Camunda) — animate tokens through a BPMN diagram.
- **Camunda Cockpit** — at runtime, visualises which task currently holds an instance's token.
- **ProM token-replay plug-ins** — replay event-log traces over a model, surfacing where tokens fail to flow as expected ([[concepts/conformance-checking]]).

## Mapping to Petri-net theory

BPMN's token semantics is essentially **Petri-net token-flow** ([[concepts/workflow-net]]) with notational sugar:

| BPMN | Petri net |
|---|---|
| Activity | Transition |
| Sequence flow | Place + arc structure |
| Token | Token |
| AND-split | Transition with multiple output places |
| AND-join | Transition with multiple input places |
| XOR-split | Multiple transitions sharing an input place (free-choice) |
| End event | Sink place *o* |

This mapping is what makes BPMN models **mechanically verifiable** for soundness via standard Petri-net tools — see [[sources/1998-vanderaalst-verification-of-workflow-nets]] §3.

## Related
[[concepts/workflow-net]] · [[concepts/soundness]] · [[concepts/deadlock]] · [[concepts/livelock]] · [[concepts/lack-of-synchronization]] · [[concepts/dead-activity]] · [[concepts/conformance-checking]] · [[concepts/7pmg]] · [[frameworks/bpmn]]

## Sources
[[sources/2018-dumas-fundamentals-of-bpm]] §3.1, §3.2 · [[sources/1998-vanderaalst-verification-of-workflow-nets]] (formal foundation)