Participants
Pool
Container for a process. A participant in an interaction. Pools exchange data only via message flows. Can be collapsed to hide details.
Lane
A band inside a pool that shows who performs the tasks (a job title, role, department, or IT system).
Activities
Task types
Abstract (None Task)
Type is not specified. Used in early modelling when the execution method is not yet decided, or when it is irrelevant for the diagram's goal. Essentially a placeholder that is later refined into a concrete type.
User Task
Performed by a human via a software interface: a CRM form, a screen in a web app, an item in a task manager. The key difference from a manual task is that the person works inside the system that tracks the task's status.
Manual Task
Performed by a human without involvement of the BPM engine. The system cannot automatically detect when this work starts or ends.
Service Task
Executed automatically by a program or a service. No human is involved. The most common task type in executable processes.
Send Task
Sends a message to a specific external participant (another process or system) and finishes immediately, without waiting for a reply. A fire-and-forget pattern.
Receive Task
Waits for an inbound message from an external participant. The process pauses at this task until the message arrives.
A special variant is the instantiated Receive: if such a task is the first step in a process, receiving the message itself spawns a new process instance (an alternative to a message start event).
Script Task
Runs an embedded script (code) defined directly inside the process model. Unlike a service task, the code does not call any external system — it runs inside the BPM engine.
Business Rule Task
Invokes a decision engine (e.g. a DMN table). Inputs are fed into a rule set, and a decision is returned.
Task markers
Small icons in the centre of the bottom of a task rectangle. They indicate the task's behaviour — not its type.
| Marker | Meaning | Example |
|---|---|---|
| ↻ Loop | The task repeats while a condition holds (one instance, several iterations) | Revise a document → submit → if rejected, repeat |
| ∥ Parallel multi-instance | N instances start at the same time — one per item in the collection | Send the notification to every approver at the same time |
| ≡ Sequential multi-instance | Same N instances, but one after another | Interview each candidate in turn |
| ⏪ Compensation | A rollback task: runs only when compensation is triggered, to undo an action that has already completed | “Cancel booking” after “Book hotel” has already completed |
| ~ Ad-hoc | Tasks inside the subprocess run in any order, can be repeated or skipped; start and end events are not allowed inside | Free choice of steps during a client consultation |
| + Subprocess | A composite activity with a hidden internal sequence; flows cannot cross its boundary | “Order processing” hides 10 internal steps |
Subprocess
A composite activity marked with “+”. Contains its own sequence of steps. Flows cannot cross its boundary. Intermediate events attach to the boundary.
Call Activity
Thick border. References a global subprocess (e.g. “Procurement”) that is reused across different processes.
Ad-hoc subprocess
Marker “~”. Activities inside may run in any order, repeat, or be skipped. Start/end events are not allowed inside.
Event subprocess
Dashed border inside a process. Triggered by a start event while the parent is active. Interrupting — cancels the parent. Non-interrupting — runs in parallel.
Gateways
Control branching and merging. A gateway is not a task! The decision is made before the gateway.
Exclusive (XOR) Gateway
The most common gateway. When splitting, it activates exactly one outgoing path — the one whose condition holds first. If no condition is met, the process fails with an error (so it is good practice to always define a “default” branch). When merging, it lets every arriving token through immediately, without waiting for the others.
Analogy: a fork in the road where you drive in only one direction.
Parallel (AND) Gateway
When splitting, it activates all outgoing paths at once, unconditionally — no checks. When merging, it waits for tokens on all incoming paths and only when all have arrived does it pass a single token onwards.
Analogy: a manager hands out tasks to five employees and waits until all five are done.
Inclusive (OR) Gateway
A hybrid of XOR and AND. When splitting, it activates one or more paths depending on the conditions — each condition is evaluated independently. When merging, it waits only for tokens on the paths that were actually activated (not for all of them, as AND does).
Analogy: a buffet — you take one dish, two, or all, but never zero.
Event-based Gateway
Fundamentally different from the others: it routes not by data, but by whichever event arrives first. After the gateway you place intermediate waiting events (timer, message, conditional, signal). As soon as one fires, the others are cancelled.
Analogy: you ordered a pizza — if it has not arrived in 60 minutes, call the pizzeria; if it arrives earlier, you eat.
Complex Gateway
Used when the branching logic cannot be expressed by standard gateways. The merge condition is defined by an expression (for example, “continue when 3 out of 5 branches have completed” or “when the first reply has arrived and 10 minutes have passed”).
None (Default Exclusive)
A diamond with no marker. Semantically equivalent to an exclusive (XOR) gateway — the BPMN standard allows omitting the cross. Some methodologists consider this bad practice because it hurts readability: it is unclear whether the author forgot the marker or deliberately chose XOR.
Events
Key concepts
An event is something that happens (a fact), as opposed to a task (an active action). Drawn as circles.
Catching (unfilled marker) — waiting. Throwing (filled) — throwing. Boundary events: interrupting (solid) and non-interrupting (dashed).
Event summary table
Icons from bpmn-font (Camunda). “—” = not defined by the standard.
| Type | Start | Intermediate | End | |||||
|---|---|---|---|---|---|---|---|---|
| Normal | Event sub. | Non-int. | Catch | Boundary | Bound. non-int. | Throw | ||
| None | — | — | — | — | — | |||
| ✉ Message | ||||||||
| ⏱ Timer | — | — | ||||||
| ⚡ Error | — | — | — | — | — | |||
| ▲ Signal | ||||||||
| 📋 Conditional | — | — | ||||||
| ↗ Escalation | — | — | ||||||
| ⬤ Terminate | — | — | — | — | — | — | — | |
| ⏪ Compensation | — | — | — | — | ||||
| ✖ Cancel | — | — | — | — | — | — | ||
| ➡ Link | — | — | — | — | — | — | ||
| ⬠ Multiple | ||||||||
| ➕ Parallel mult. | — | — | ||||||
Message
Exchange with a specific recipient: email, call, HTTP, push. Available in every position.
Timer
Date/time, interval, countdown (deadline). Catching only.
Error
A serious failure. Catching — only on a boundary. Throwing — only at the end.
Conditional
Waiting for an external condition (“the oven is hot”). Catching only.
Signal
Broadcast (vs. an addressed message). Any subscriber reacts.
Terminate
Immediately stops the entire process instance. End only.
What if continuing task 2 after task 3 finishes no longer makes sense? Then the pattern below is used:
Link
A flow “teleport”. A paired throw + catch replaces a long arrow. Intermediate only.
Compensation
Reverses a previously completed action. The compensating task is linked via an association.
Escalation
Sent from a subprocess to its parent — not an error. Can be non-interrupting.
Cancel
Only in the context of transactions. End — rollback. Boundary — catch.
Data, artefacts, flows
Data Object
A “sheet of paper” with a folded corner. Represents information that is created, consumed or passed between tasks within a process instance. It only exists while the instance is alive.
Data Store
A cylinder. Persistent storage that outlives the process instance: a database, a registry, a file store. Tasks read from and write to it.
Data Input / Data Output
Parameters of a process or subprocess on its boundary. Input — what is supplied from the outside; output — what is returned. Arrow with an open/filled triangle.
Text Annotation
A comment attached to any element via a dashed line. Does not affect execution — it only exists to clarify things for the diagram's reader.
Group
A dashed rounded rectangle. A visual grouping of elements (e.g. “all logistics tasks”). It has no execution semantics; flows may freely cross its boundary.
Sequence Flow
A solid arrow with a filled head. Defines the order of execution inside a single pool. Cannot cross pool boundaries.
A conditional flow (with a small diamond at the source) — fires only if its condition is true. Used on outgoing arrows from a task without a gateway.
A default flow (with a tick at the source) — the fallback path of an XOR/OR gateway or a conditional split, taken if no other condition holds.
Message Flow
A dashed arrow with an open head. Connects different pools — a message exchanged between independent participants. Not used inside a single pool.
Transaction
A subprocess with a double border. ACID semantics: either every inner action commits successfully, or the entire transaction rolls back via a Cancel event (with compensations). Used for consistency in distributed operations.