Lanes in BPMN: ten common mistakes and how to avoid them

Pools and lanes in BPMN seem like simple concepts: a pool is a process participant, a lane a role inside the pool. But working with pools and lanes is exactly what becomes the source of most mistakes in real models. In this piece — ten common mistakes and recommendations for fixing them.

1. A sequence flow between pools

The most common mistake. Between pools you must use only a message flow, not a sequence flow. Pools are independent processes, and they cannot pass tokens to one another directly.

2. Gateways on a pool boundary

Placing a gateway that splits the flow into branches in different pools is a conceptual mistake. A gateway controls a token within a single process. If different branches are to be performed by different participants, you must use message flows and message events.

3. Lanes instead of pools

Using lanes to denote external participants (suppliers, customers, other organizations) is a mistake. Lanes describe roles within a single organization/process. For external participants always use separate pools.

4. A black box with a description

A pool drawn as a “black box” (a collapsed pool) must contain no internal elements. It is a contract: we know that we interact with this participant but do not describe its internal processes. A common mistake is drawing a black box and its internal processes at the same time.

5. A user task without a lane

If a process has user tasks, they must be placed in the corresponding lanes that denote the performers. Placing a user task outside a lane makes the model incomplete — it is unclear who performs it.

6. Excessive lane granularity

Creating a lane for each specific employee turns a diagram into an unreadable mess. Lanes should correspond to roles, not individuals. If ten managers take part in a process, that is one “Manager” lane.

7. Overloaded pools

If a pool has more than 5–7 lanes, that is most likely too many. Consider decomposition: perhaps you have not one process but several related ones, each with its own participants.

8. Pools without events

Every pool that describes its own process must have explicit start and end events. Analysts often skip them, relying on the pool boundaries being “obvious anyway”. This violates the BPMN specification.

9. An event-based gateway for receiving messages

If a process waits for one of several possible messages from another participant, use an event-based gateway, not an XOR gateway with intermediate events. The semantics differ substantially: an event-based gateway is activated by the first message to arrive, an XOR gateway by a specific data-based condition.

10. Choreography instead of collaboration

BPMN has two different notations for describing interaction:

• Collaboration diagram — shows the participants’ processes in pools and the message flows between them
• Choreography diagram — shows only the exchange of messages without the participants’ internal logic

Using collaboration where choreography is needed (for example, to describe B2B protocols) leads to excessive complexity. And conversely, using choreography for internal processes loses important information about the participants’ logic.

Conclusion

Pools and lanes are basic BPMN constructs, but their correct use requires an understanding of the semantics. If you are only learning BPMN, it is worth working through the relevant sections of the official OMG specification separately. These constructs are the foundation on which the correctness of the whole model is built.