The elements · 07 · 8 min
Pools, lanes and message flow
The rule that catches almost every beginner: sequence flow must never cross a pool boundary.
A pool is a participant: a company, a customer, a system. Each pool holds one process, with its own tokens. A lane subdivides a pool by role and has no execution semantics at all: it is organisational labelling.
Because each pool runs its own process, control cannot flow between them. Pools communicate only by message flow.
Supplier: an order message starts the process, goods are picked, the shipment is confirmed. Customer is a collapsed pool; only message flows cross.
Lab · Is this connection correct?try the wrong combinations on purpose
Incorrect
Don't connect an element to itself. To repeat work, use a loop marker on the activity, or route back through a gateway.
Two pools, two processes, and exactly one kind of arrow allowed to cross between them. The table is the rule in full.
| Connector | May connect | Must never |
|---|---|---|
| Sequence flow | Two flow nodes inside the same pool, across lanes is fine | Cross a pool boundary |
| Message flow | Two elements in different pools, or pool-to-pool directly | Connect two elements in the same pool |
| Association | An artifact (annotation, data object) to any element | Carry execution meaning |
Black-box pools
After this module you can
- Decide when to use sequence flow versus message flow
- Explain why lanes carry no execution semantics
- Use a black-box pool for a participant you do not model