Episode 4 · April 9, 2026 · Hosted by Sebastian
Pools vs. Lanes: When to Separate External Stakeholders
When to use pools and when to use lanes, shown on Susan's sample box process from the course with an external supplier. We modelled it twice, without pools and with a collapsed supplier pool, to show how pools expose the external dependencies you can't optimise away and make supplier reporting and compliance checks possible.
Pools vs. lanes: where your organisation ends and someone else's begins.
The big takeaway
Pools mark organisational boundaries. Lanes mark internal roles.
Mix them up and your diagram says something fundamentally different from what you intended, starting with how much of the process you actually control.
What we walked through
- 01
Pools are organisational boundaries, lanes are internal roles
External parties such as suppliers, customers and partners are separate pools. Internal departments are lanes inside the same pool.
- 02
Why it matters for control and ownership
We modelled Susan's sample box process from the course two ways: first without pools, then with a collapsed supplier pool and message events. Without pools, the diagram implies 100% control. With pools, you immediately see the external dependencies you can't optimise away.
- 03
Collapsed pools as the default
You don't need to model the supplier's internal process. You care about what you send and what you receive. Keep it collapsed unless you have an exclusive relationship where you dictate their process.
- 04
The reporting and compliance angle
When modelled correctly, you can scan your entire process landscape for every supplier interaction. Processes without proper pool boundaries fall through the cracks. The same goes for compliance: supplier data exchange is always the more sensitive piece.
- 05
Internal communication doesn't need message events
A sequence flow crossing a lane boundary already implies a handover. No extra tasks or message events are needed between departments.
Discuss this episode
Ask a question, share how you would model it, or suggest the next topic.
More episodes
All episodes →The Hidden Context Layer: Clean Diagrams, Rich Metadata
How to make diagrams leaner and smarter at the same time. Instead of stacking labels on tasks, we put time, cost, system, owner and risk into a structured attribute layer behind the canvas, then looked at the reporting, system mapping and compliance use cases that layer unlocks.
BPMN Meets AI: How to Bring AI Into Operations
A playbook for bringing AI into operations with BPMN. We took a sales qualification process and found two agent opportunities, a pre-qualification scorecard and a business case generator, scoped what each needs, built human review into the to-be, and used time-per-task attributes to decide which pilot to build first.
Where Should AI Go First? Prioritizing Processes and Tasks With Attributes
How to prioritise AI initiatives from your process models instead of case by case. We ran two passes: on the process level, two simple attributes and a filter produced a shortlist; on the task level, value potential against feasibility picked the first initiatives. In our example that left five concrete opportunities.