BPMN & Business Process Analysis

Pools, Lanes & Collaboration

18 min Lesson 6 of 10

Pools, Lanes & Collaboration

Up to this point you have modeled processes that live inside a single organization — a sequence of tasks flowing through gateways to an end event. Real business processes rarely stay inside one boundary. An online order crosses from the Customer to the Online Store to the Logistics Partner. A clinic appointment moves between the Patient, the Reception, and the Doctor. BPMN handles this reality through two structural containers: pools and lanes.

What Is a Pool?

A Pool is the outermost BPMN container. It represents a single participant — a whole organization, a system, or an autonomous party that has its own process. Think of it as a swim lane for an entire team. Each pool owns its own sequence flow; you cannot draw a sequence-flow arrow directly from one pool into another pool. That separation is intentional: it models the fact that one organization cannot directly control another organization's internal steps.

Participant vs. role: A pool represents a participant at the organizational or system level (e.g., "Logistics Partner"), while a lane represents a role or department within that organization (e.g., "Warehouse Team" vs. "Dispatch Team").

What Is a Lane?

A Lane is a horizontal (or vertical) subdivision inside a pool. Each lane is labelled with a role, department, or system responsible for the tasks placed in it. Lanes do not restrict sequence flow — a flow can cross lane boundaries freely within the same pool. They exist purely to clarify who does what, making the diagram readable to both technical and non-technical stakeholders.

Lanes are especially useful when you need to model a cross-functional process without yet worrying about inter-organizational communication. For example, a Purchase Order approval process might have lanes for Requester, Department Manager, and Finance, all inside a single "Company" pool.

Message Flow: Connecting Two Pools

When two pools need to exchange information, BPMN uses a Message Flow — a dashed arrow with an open arrowhead, optionally decorated with a small envelope icon. Message flows only connect elements that belong to different pools. They do not affect the internal sequence logic of either pool; they simply show that data or a trigger crosses the organizational boundary.

A Message Start Event (a circle with an envelope) and a Message End Event (a thick circle with a filled envelope) are commonly used at the boundary points where one participant sends and the other receives.

Analyst tip: If you find yourself wanting to draw a solid sequence-flow arrow between two pools, stop — that is a modeling error. Convert it to a dashed message flow. If the two parties actually share the same command structure, they should be in the same pool as separate lanes.

Collaboration Diagram: Order Fulfillment

The diagram below models a simplified online order fulfillment collaboration between two pools: the Customer (a black-box pool — its internal process is not our concern) and the Online Store (a white-box pool with two lanes: Sales and Warehouse). Dashed message flows show what each party sends to the other.

Two-pool BPMN collaboration: Customer (black-box) and Online Store (white-box with Sales and Warehouse lanes). Dashed blue arrows are message flows; solid grey arrows are sequence flows.

Reading the Diagram as an Analyst

Step through what happens: the Customer sends an Order Request message (dashed arrow) that triggers a Message Start Event in the Sales lane. Sales validates the order and checks stock at an exclusive gateway. If stock is unavailable, the flow notifies the Customer and ends. If stock is available, Sales confirms and sends an Invoice (another message flow) back to the Customer. Internally, a trigger passes to the Warehouse lane, which picks and packs the items, ships the order, and fires a Dispatch Notice message flow to the Customer, completing the collaboration.

Notice that the Customer pool is drawn as a collapsed pool (a plain box with just the pool label and two events visible). This is common when you are not the analyst for that participant — you know the interface but not the internal details. A white-box pool exposes all internal lanes and tasks, as the Online Store pool does here.

Best Practices

One pool per autonomous participant. If the IT system and the Sales team are both inside the same company, they belong in lanes of the same pool — not separate pools.
Keep message flows minimal. Every dashed arrow is an integration point — a potential bottleneck or failure mode. Fewer is better.
Name your message flows. Label each dashed arrow with the data or document being exchanged (e.g., Purchase Order, Shipping Confirmation). This becomes your interface specification.
Validate with stakeholders by pool. Show each participant only their pool (or at most the collaboration view) during interviews — it keeps the conversation focused.

Common mistake: Drawing sequence flows between pools is invalid BPMN and will cause process engine errors. Always use message flows to cross a pool boundary, and use message events (start, intermediate, or end) to mark the receiving and sending points clearly.

Practical Application: When to Use Which

Use lanes only when you are mapping an internal process and accountability is the main concern (e.g., an IT change-management workflow inside one company). Use multiple pools with message flows when you are modeling a business ecosystem: a customer portal, a payment gateway, and your backend — three autonomous participants that communicate via defined interfaces. Collaboration diagrams are particularly valuable during the As-Is analysis phase (Lesson 7) because they expose integration complexity that a single-pool diagram hides entirely.