Direct Answer
In BPMN, a Pool represents a participant: a distinct organization, system, or autonomous process engine. A Lane subdivides a pool by role, department, or function within a single participant. Message Flows connect pools: they represent communication between separate participants. Sequence Flows connect activities within a pool: they represent process flow within a single participant. The rules are strict: Sequence Flows cannot cross pool boundaries; Message Flows cannot exist within a pool. Using Sequence Flows between pools is the most common cross-organisational BPMN error. A Black Box Pool shows an external participant without revealing their internal process: only the message interfaces are visible. In Sparx EA, pools and lanes are modelled using the BPMN 2.0 Pool and Lane elements from the toolbox, with Message Flow as the cross-pool connector type.
Pool: The Participant Boundary
A Pool is the process container for a single participant. Everything inside a pool belongs to that participant: all activities, gateways, events, and sequence flows are the participant’s internal process.
When to create a Pool:
- The participant is a different organization (your company and a customer; your company and a supplier)
- The participant is a separate autonomous system (an ERP, a CRM, an external API)
- The participant has a separate process engine that cannot see the internal state of the other participant
When not to create a Pool:
- Subdivisions of the same organization. A purchasing department and an accounts payable department within the same company are not separate pools: they are lanes in the same pool.
- Sub-processes within the same system. Activities performed by different modules of the same application belong in lanes, not pools.
The key test: Can the two participants see each other’s internal state? If no: if they can only communicate via defined messages: they are separate pools. If yes: if one participant’s process can branch based on the other’s internal state: they are lanes in the same pool.
Lane: Subdivisions Within a Participant
A Lane represents a role, department, team, or system that performs specific activities within the participant’s process. Lanes do not change the semantics of the process: they are organisational annotations. Sequence Flows can cross lane boundaries freely; this is how handoffs within an organization are shown.
Lane types in practice:
Role-based lanes: Loan Officer, Underwriter, Compliance Officer, Customer Service Representative. The lane shows who performs each activity.
Department-based lanes: Sales, Finance, Legal, Operations. The lane shows which department is responsible.
System-based lanes: CRM System, ERP System, Workflow Engine. For process models where both human and system activities are shown within a single organization’s process.
Lane nesting. BPMN 2.0 allows lanes to be nested: a department lane contains role lanes. Use this for complex organisational processes where both department-level and role-level assignment is needed. In Sparx EA, nested lanes are created by adding sub-lanes within a parent lane in the BPMN toolbox.
Black Box Pool: The External Participant
A Black Box Pool shows that an external participant exists and interacts via messages: but their internal process is hidden. No activities, gateways, or sequence flows are shown inside the pool. Only the pool boundary and the Message Flows connecting to it.
When to use Black Box Pools:
- When modeling from the perspective of your own organization’s process: the external participant’s internal process is not relevant, not known, or not yours to specify
- When the diagram would become unreadably complex if both participants’ full processes were shown
When to expand:
- When the process model is collaborative: showing both participants’ processes and their interactions. This is the “collaboration diagram” pattern in BPMN.
In Sparx EA, a Black Box Pool is created by drawing a Pool element and leaving its interior empty. Add Message Flows connecting the Black Box Pool boundary to specific activities or events in your own pool.
Message Flows: Communication Between Pools
Message Flows are the communication lines between pools. They represent a message, data exchange, or signal crossing from one participant to another. Message Flows are dashed lines with an open arrowhead and optionally a message envelope icon at the source or target.
Message Flow rules:
- Message Flows connect activities (tasks or events) in one pool to activities (tasks or events) in another pool
- Message Flows cannot connect items within the same pool (that is what Sequence Flows are for)
- Message Flows can connect to the pool boundary (for Black Box Pools) or to specific activities/events within an expanded pool
Message Flow direction matters. The arrowhead indicates which participant sends. A Message Flow from an activity in Pool A to an activity in Pool B means Pool A sends a message that Pool B receives.
Message types. In BPMN, Message Flows can be typed with Message elements: artefacts that describe the message content. In Sparx EA, create a Message artefact, name it (e.g., “PurchaseOrder”, “InvoiceApproval”, “CreditDecision”), and attach it to the Message Flow. This makes the collaboration diagram a formal interface specification.
Collapsed vs Expanded Pools
An expanded pool shows the internal process: all activities, gateways, events, and lanes are visible. An expanded pool is appropriate when you own the process and need to specify it.
A collapsed pool shows only the pool boundary. It is appropriate for:
- Black Box Pools (external participants whose process is not specified)
- Your own sub-processes that are modelled in detail on a separate diagram
- Simplifying a complex collaboration diagram by hiding one participant’s detail
In Sparx EA:
- Expanded Pool: draw a Pool element and populate it with activities and lanes
- Collapsed Pool: draw a Pool element, leave it empty, and resize it to a narrow band
When to collapse your own pool: when presenting a process model to external stakeholders who need to see only the interface (what messages you send and receive) without your internal process detail.
Modeling Cross-Organisational Processes in Sparx EA
Setup for a supplier-buyer collaboration model:
- Draw two expanded Pools, one for the Buying Organization and one for the Supplier
- In the Buying Organization Pool, add lanes: Procurement, Finance
- In the Supplier Pool, add lanes: Sales, Fulfillment, Accounts
- Model the internal process within each pool using Sequence Flows between activities in different lanes
- Connect activities across the pool boundary using Message Flows:
– Purchase Order: from Procurement activity → Supplier Sales boundary or activity – Order Acknowledgement: from Supplier Sales → Procurement – Invoice: from Supplier Accounts → Buying Organization Finance – Payment Confirmation: from Finance → Supplier Accounts
The resulting collaboration diagram shows both organizations’ internal processes and their message exchange. This is the complete picture that an integration architect or process analyst needs when designing cross-organisational automation.
For system integration use cases: Model the application system as a Pool (it is an autonomous participant). Show message flows between the human process pool and the system pool. This produces an interface specification: what messages the system sends and receives, and at which process step.
Frequently Asked Questions
Q: Can a process have activities in both a pool and directly on the diagram (no pool)? A: No. If you have a pool, all participants must be in pools. Activities outside a pool are considered an implicit, unnamed pool: this is technically allowed in BPMN 2.0 but produces ambiguous diagrams. Always place all process elements inside explicitly named pools.
Q: How many lanes should a pool have? A: As many as needed to show meaningful role or department separation. A pool with more than six or seven lanes becomes visually cluttered. If you need more than six lanes, consider whether the process should be decomposed across multiple diagrams: a top-level process and expanded sub-process diagrams for each major phase.
Q: What is the difference between a Message Flow and a Message Intermediate Event? A: A Message Flow is a connector between pools showing communication. A Message Intermediate Event (Catch or Throw) is an event element within a process that represents the act of sending or receiving a message. When a process activity explicitly sends a message (shown as a Throw Intermediate Event), the Message Flow connects from that event to the receiving pool or activity. The Message Flow is the channel; the Message Event is the act.
Q: Should IT systems be shown as pools or as lanes? A: Systems that operate autonomously: that have their own process engine, trigger their own activities, and communicate via APIs or messages: should be Pools. Systems that are tools used by human performers (a person using a CRM to enter data) are lanes or are shown as data objects within a human-performed lane. The test: does the system have its own internal process logic, or does a human operate it?
Q: How do collapsed pools work with message flows? A: Message Flows connect to the collapsed pool’s boundary (not to specific internal activities, since they are hidden). This is the Black Box Pool pattern. The Message Flow simply says “this message enters the pool” or “this message exits the pool” without specifying which internal activity handles it. When you expand the pool later, refine the Message Flows to connect to specific activities.
Q: How does Sparx EA handle the visual formatting of pools and lanes? A: In Sparx EA’s BPMN 2.0 toolbox, Pool and Lane elements have toolbar options for orientation (horizontal or vertical lanes), lane sizing, and lane label position. Message Flows are drawn using the Message Flow connector type from the BPMN toolbox: not a standard UML association. Sparx EA automatically enforces that Message Flows cannot be placed between elements within the same pool.
Next Step
Process models that accurately represent cross-organisational interaction: with correct pool/lane/message flow structure: are the foundation of process automation design, integration architecture, and digital transformation planning. The Amplify engagement includes BPMN standards, cross-organisational process modeling methodology, and the review process to ensure your process models are fit for purpose.
