BPMN Lanes vs Pools: Who Does What in a Workflow Diagram
Monday, September 8, 2025
Are your lanes swimming in the wrong pool?
Misusing pools and lanes isn’t just a diagramming slip—it can cause misaligned teams, brittle automation, and BPMN diagrams that confuse more than they clarify. Even seasoned modelers stumble here, especially when switching between business and technical perspectives. This guide shows how to choose pools and lanes correctly so your workflow diagram reflects reality and can be implemented with confidence.
First: Know What You’re Modelling
BPMN Pool
A pool represents a participant in a collaboration—an independent actor with its own process logic (an organization, external customer/vendor, or an autonomous system).
BPMN Lane
A lane subdivides a single participant by roles, teams, or departments. It clarifies who does what inside that participant.
Key distinction: Pools define boundaries; lanes define responsibilities. Use pools to show between-participant interactions (messages). Use lanes to organize within-participant work (sequence flows).
Guardrails You Should Never Violate
- No sequence flows across pools. Use message flows between pools.
- Message events belong only between pools. Never use them for handoffs within one pool.
- Don’t straddle a task across pools. Communicate via messages; execute within one participant.
1) Business-Oriented Process
Focus: Collaboration across people, teams, and departments to deliver a business outcome.
- Pools: Represent independent participants (e.g., your company, a vendor, or a customer).
- Lanes: Show roles or departments within a single participant to clarify “who does what.”
Key idea: Roles in the same organization belong in lanes of one pool—not in separate pools.
Common mistake: Splitting departments into separate pools when they’re not independent participants.
Example: - Pool: “Donut Depot”
- Lanes: Sales Rep, Accountant, Fulfilment Clerk
- Pool: “Customer” – interacts with Donut Depot via message flows.
2) Technical / Integration Process
Focus: How systems exchange data to drive a process.
- Pools: Represent individual systems (CRM, ERP, Payment Gateway). Even if they belong to the same organization, treat them as independent participants because they communicate externally via APIs or messages.
- Lanes: Rarely needed—only if you want to show internal modules or subsystems.
Key idea: Each system is its own participant—model them as separate pools with message flows between them.
Common mistake: Merging systems into one pool and losing visibility of their interactions.
Example: - Pool: CRM
- Pool: ERP
- Pool: Payment Gateway
Message flows: API calls and data exchanges between each.
Quick Reference Table
| Type | Business Process | Technical Process |
|---|---|---|
| Pools | Separate participants like companies, customers, vendors—connect via message flows | Separate systems (CRM, ERP)—connect via APIs/messages |
| Lanes | Teams, departments, roles within the same participant | Rarely used—only for subsystems |
Pro Tip: Get “Participant” Right First
A participant in BPMN is any independent actor with its own process logic:
- Business: an organization, vendor, or customer.
- Technical: a system (CRM, ERP, Payment Gateway).
Ask yourself: - Am I showing different roles within the same organization or system? → Use lanes.
- Am I showing interactions between separate organizations, people, or systems? → Use pools.
These two questions clear up 90% of lane vs. pool confusion.
Try it in Crismo
Model a customer order from both perspectives—business and technical—in crismo.io and see how your diagram changes.
Pools define the boundaries. Lanes define the roles. They’re not decoration—they’re the structure of your model. Get this distinction right, and even the most complex process becomes easy to follow.