Pool

A pool is a labelled rectangle that contains an entire process for one participant. The pool’s label is the participant — typically a company ("Acme Corp"), a department ("Compliance"), a role at scale ("Customer"), or a system ("Stripe"). Everything inside the pool happens within that participant’s scope. Everything between pools happens at the boundary between participants.

A pool can be *expanded* (showing the full internal process) or *collapsed* (drawn as a flat black box with only its name visible). A collapsed pool is a design choice: use it when you want to acknowledge the other participant exists — so you can draw message flows to and from it — without committing to modelling their internal process. The canonical example is an external customer or a third-party API.

• One pool per participant. If "our sales team" and "our finance team" are both inside one organisation, they are lanes inside one pool, not two pools.
• Sequence flows never cross a pool boundary. A sequence flow between pools is always a modelling error — use a message flow instead.
• A pool that participates in a collaboration but has nothing to model internally should be collapsed. Leaving an empty expanded pool is noise.
• Each expanded pool gets its own start and end events. You cannot span one flow across two pools.

When the source document describes interactions between multiple organisations or systems, LucidFlow produces a collaboration diagram — one pool per named party. External parties whose internal processes are irrelevant ("the customer", "the payment processor") are rendered as collapsed pools connected by message flows. The cost dashboard separates costs per pool, which is how you see "how much does this process cost *us*" distinct from "what happens on the other side of the boundary".