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.