Container for a process. A participant in an interaction. Pools exchange data only via message flows. Can be collapsed to hide details.
A band inside a pool that shows who performs the tasks (a job title, role, department, or IT system).
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.
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.
Performed by a human without involvement of the BPM engine. The system cannot automatically detect when this work starts or ends.
Executed automatically by a program or a service. No human is involved. The most common task type in executable processes.
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.
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).
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.
Invokes a decision engine (e.g. a DMN table). Inputs are fed into a rule set, and a decision is returned.
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 |
A composite activity marked with “+”. Contains its own sequence of steps. Flows cannot cross its boundary. Intermediate events attach to the boundary.
Thick border. References a global subprocess (e.g. “Procurement”) that is reused across different processes.
Marker “~”. Activities inside may run in any order, repeat, or be skipped. Start/end events are not allowed inside.
Dashed border inside a process. Triggered by a start event while the parent is active. Interrupting — cancels the parent. Non-interrupting — runs in parallel.
Control branching and merging. A gateway does no work itself — it only routes the flow; the task before it prepares the decision.
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.
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.
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.
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 send a job offer and wait: if the candidate replies, you go on; if a week passes in silence, you move to the next candidate.
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”).
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.
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).
“—” = 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. | — | — | ||||||
Exchange with a specific recipient: email, call, HTTP, push. Available in every position.
Date/time, interval, countdown (deadline). Catching only.
A serious failure. Catching — only on a boundary. Throwing — only at the end.
Waiting for an external condition (“stock falls below the minimum”). Catching only.
Broadcast (vs. an addressed message). Any subscriber reacts.
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:
A flow “teleport”. A paired throw + catch replaces a long arrow. Intermediate only.
Reverses a previously completed action. The compensating task is linked via an association.
Sent from a subprocess to its parent — not an error. Can be non-interrupting.
Only in the context of transactions. End — rollback. Boundary — catch.
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.
A cylinder. Persistent storage that outlives the process instance: a database, a registry, a file store. Tasks read from and write to it.
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.
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.
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.
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.
A dashed arrow with an open head. Connects different pools — a message exchanged between independent participants. Not used inside a single pool.
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.
Talk to our team — we’ll map your process and show BP1.ai running BPMN on your own data.
Contact Sales