Pool and lane (BPMN)
In BPMN 2.0, a pool is the outer container representing one participant in a process — usually a whole organisation or a major system. A lane sits inside a pool and represents one role, team or department within that participant. Every task, event and gateway lives in exactly one lane.
The distinction matters in practice. Lanes let you show who inside an organisation does what — the accountability view. Pools let you show how two parties interact at arm's length — typically via message flows rather than sequence flows. A process with one organisation and five roles is usually one pool and five lanes. A process with a customer, an organisation and an external payment provider is usually three pools exchanging messages.
Two-pool example: bank payment
Two pools — Customer and Bank Teller — connected by message flows (dashed arrows). The Customer pool submits a payment and later receives a receipt; the Bank Teller pool verifies the request, routes through an exclusive gateway and processes or returns funds. Two pools, not lanes, because the customer and the bank are arm's-length participants — so they exchange messages rather than share a sequence flow. The Customer pool intentionally models the happy path only; the rejection branch terminates inside the Bank pool, which is a common modeling choice when the customer-side rejection workflow is out of scope.
Making a payment at a bank
A two-pool BPMN 2.0 collaboration for making a payment at a bank. The Customer pool submits a payment and later receives a receipt; the Bank Teller pool receives the request, verifies the details, and routes through an exclusive gateway ("Are payment details valid?") — processing the transaction and providing a receipt on the yes path, or returning funds on the no path. Two message flows connect the pools: the customer sends the payment request to the bank, and the bank sends the receipt back.
- Customer submits the payment — the Payment Initiated start event fires the Submit Payment task.
- A message flow carries the request to the Bank Teller pool, triggering the Payment Request Received start event.
- Bank Teller verifies the payment details, then the "Are payment details valid?" exclusive gateway decides the path.
- On the no path, Bank Teller returns the funds and the Bank Teller process ends at Payment Rejected.
- On the yes path, Bank Teller processes the payment transaction and provides a receipt, ending at Payment Processed.
- A second message flow delivers the receipt back to the Customer pool, where the Receive Receipt task runs and the Customer process ends at Payment Completed.
Pool vs lane vs swimlane
Three terms that people use almost interchangeably but that BPMN treats differently.
Pool — one participant
The outer box. One pool per participant. Use a pool for every party that only interacts with the process at arm's length: customers, external suppliers, regulators, third-party systems. Pools exchange information through message flows (dashed arrows), not sequence flows.
Lane — one role inside a pool
A subdivision of a pool. One lane per role, team or department. Lanes share a pool because the whole point of a lane is to show internal coordination — tasks in different lanes can be connected with normal sequence flows (solid arrows).
Swimlane — informal umbrella term
Predates BPMN. Most people use “swimlane” loosely to mean a lane, and that usage is widely understood. In strict BPMN 2.0 vocabulary, swimlane is not an official element — the spec only defines pool and lane. See swimlane diagram for the broader term.
How to set up pools and lanes in 5 steps
1. List every party that takes part in the process
Write down every person, team, department or system that does something in the flow. Do not worry yet about pools vs lanes — just get the full list on the page.
2. Separate internal parties from external parties
Internal parties (teams inside the same organisation running the process) go into one shared pool as lanes. External parties (customers, suppliers, third-party systems) each get their own pool.
3. Name the main pool after the participant, not the process
The pool label is the participant ("Acme Bank", "Customer service agent"), not the process name. The process name lives on the pool's title strip at the very top.
4. Order the lanes by who acts first
Put the lane of whoever starts the process at the top. Later lanes follow the order of hand-offs. This makes the diagram read top-to-bottom as well as left-to-right.
5. Keep to six lanes or fewer
Three to six lanes is the readable maximum. If you need more, combine roles that always act together, or break the process into smaller sub-processes each with its own lane set.
Pool and lane FAQ
What is the difference between a pool and a lane in BPMN?
A pool is the outer container representing one participant — usually a whole organisation or a major system. A lane sits inside a pool and represents one role, team or department within that participant. Pools are for parties that interact at arm's length (via messages). Lanes are for divisions of work inside a single party.
When should I add a second pool vs add another lane?
Add a second pool when the other party is external — a customer, a supplier, a third-party system — and you only want to show the messages that cross the boundary. Add another lane when the other party is internal: a second team in the same organisation that you want to model step-by-step alongside the first.
Can a lane contain another pool?
No. In BPMN 2.0 pools and lanes nest one level deep: a pool contains lanes, and each lane contains flow elements. A lane cannot contain another pool. If the relationship you want to model is pool-inside-pool, you should either collapse the inner pool to a sub-process inside a lane, or represent the inner party as a separate pool connected by message flows.
Are pool, lane and swimlane the same thing?
"Swimlane" is a generic term that predates BPMN and covers both pools and lanes together. In strict BPMN 2.0 vocabulary, "swimlane" is not an official element — the spec only defines "pool" (participant) and "lane" (subdivision of a pool). Most people use "swimlane" loosely to mean a lane, and that usage is widely understood.
How many lanes should a BPMN diagram have?
Three to six is the readable maximum. Beyond that the diagram becomes too tall to scan and the lanes blur together. If you have more distinct roles, consider combining roles that always act together, or splitting the process into smaller sub-processes with their own lane sets.
Skip the lane setup
Describe the process — mention each role by name — and BA Copilot's AI places every task in the right lane. Add external parties as separate pools connected by message flows.