Collaboration Diagram
A BPMN diagram that shows two or more pools exchanging messages — the view you use when "the process" spans multiple organisations.
What a collaboration diagram shows
A collaboration diagram is a BPMN diagram that contains more than one pool and at least one message flow between them. Each pool is a participant — typically an organisation, a department, or a system — and message flows are the dashed lines that show which pool sends what to which other pool, and when.
If you are modelling a process that happens entirely inside one company, you do not need a collaboration diagram — a single-pool process with lanes is fine. You need a collaboration diagram the moment the process crosses a trust boundary: customer ↔ supplier, company ↔ bank, internal system ↔ third-party API. At that boundary you can no longer assume control, you can only assume messages.
The rules that matter
- Sequence flows never cross a pool boundary. Inside a pool, tasks are connected by sequence flows; between pools, they are connected by message flows.
- Each pool owns its own start and end events. You cannot start one pool and end another.
- A collapsed pool — drawn as a black box with no content — is perfectly valid when you care only about the messages, not the internal process, of a participant.
- Message flows connect activities or events on either side, not lanes. A message is always between concrete steps.
Collaboration diagrams in LucidFlow
LucidFlow detects multi-party processes during document analysis. When a transcript or SOP describes interactions between "our team" and "the supplier" or "the customer", the generator produces a collaboration diagram with one pool per participant and message flows for every asynchronous exchange. The bottleneck heatmap then colours message flows by waiting time — showing you exactly where the process stalls at an organisational handover, which is almost always the most expensive kind of delay.
Frequently asked questions
Is a collaboration diagram the same as a swimlane diagram?
No. A swimlane diagram uses lanes inside a single pool, typically to split one process by role. A collaboration diagram uses multiple pools, each representing a separate participant — different organisations, different trust boundaries.
Can I mix lanes and pools in the same diagram?
Yes, and you should. A collaboration diagram where one of the pools contains lanes is normal — the pool is the organisation, the lanes are the roles inside that organisation.
When should the other party be a collapsed (black-box) pool?
When you do not know or do not care how they run their side of the interaction. A collapsed pool documents "we send them X and they eventually send us Y" without pretending to model the internals of a system you do not own.