Understanding BPMN Pools and Lanes: Concepts, Common Misunderstandings, and Modeling Errors
This article explains BPMN pools and lanes, their definitions, white‑box vs black‑box pools, lane roles, common misconceptions, typical modeling errors such as missing or misused sequence flows and improper lane usage, and provides corrective solutions for accurate process diagrams.
In BPMN terminology, “swimlanes” refer to the two primary groupings of BPMN elements: pools and lanes.
Pool
A pool is the fundamental BPMN element that defines the boundary of a business process. A pool can contain at most one business process, meaning separate processes must be modeled in separate pools. Pools may be “white‑box” (showing internal details of the process) or “black‑box” (hiding internal details). The choice depends on the required level of detail and context.
“White‑box” pools are usually named after the corresponding business process (e.g., “Requirement Management Process”, “Help Desk Process”, or “Service Delivery Process”), while “black‑box” pools are typically named after the organization, person, or system (e.g., “Supplier”, “Customer”, or “Content Management System”).
Lane
A lane is a sub‑partition within a pool used to organize and categorize activities. Most commonly, a lane represents an organizational role (e.g., developer, analyst, manager), but lanes can also be used for other purposes such as phases (first stage, second stage, third stage).
Common Misunderstandings
The meanings of pools and lanes are often confused; for example, a set of pools may be mistakenly treated as a group of lanes within a single pool, and vice versa, leading to syntactically and semantically incorrect models.
Because of the semantic differences between pools and lanes, the way BPMN flow elements (activities, gateways, events) connect differs depending on whether they are used inside a pool or between pools. Within a pool, flow elements connect via sequence flows as shown in Figure 2.
When communicating between pools, only message flows may be used. Message flows represent the exchange of messages between two pools or processes, including synchronization, as defined in Figure 3.
Based on these misunderstandings, three common modeling errors are identified:
Error 1: Missing Sequence Flow
Issue: When modeling multiple pools (e.g., B2B scenarios with two or more interacting processes), a common mistake is that activities inside a pool are not connected by sequence flows.
Cause: Modelers often treat several pools as a single process and misinterpret message flows as indicating activity order, resulting in an invalid model lacking a defined activity sequence.
Solution. Modelers should always model and validate each pool individually and remember that a pool cannot contain multiple processes. All flow elements inside a pool must be connected using sequence flows as defined in Figures 2 and 3.
Error 2: Misuse of Sequence Flow
Issue: Another frequent problem when modeling multiple pools is treating a set of pools as a single pool with multiple lanes, then using sequence flows between pools, which produces an incorrect model that spans pool boundaries (see Figure 2).
Solution. The typical solution is to replace the lanes with separate pools in a single diagram. If multiple independent processes are needed, apply the solution from Error 1.
Error 3: Improper Use of Lanes
Issue: Sometimes a modeler mistakenly treats a lane as a pool, representing separate processes within a single lane. This is incorrect because lanes are merely a mechanism for classifying activities.
Solution. The common solution is similar to the previous one: define a single pool for the two processes (see Figure 9), removing redundant start and end events. If multiple independent processes are required, use the solution from Error 1.
Nevertheless, it is important to note that having two start or two end events in a process is not syntactically wrong; different events can start a process in different places (e.g., asynchronous message triggers or scheduled daily starts), and a process may end in different states (e.g., “successful” or “unsuccessful”).
Conclusion
This article introduced the concept of BPMN “swimlanes”, which can be modeled using pools and lanes. At first glance the two elements appear very similar, but they have completely different meanings.
A pool is a container for a single process, while a lane serves as an activity classification mechanism. Consequently, the association of BPMN flow elements differs: only message flows can be used for inter‑pool communication, whereas sequence flows are used within pools and between lanes.
Architects Research Society
A daily treasure trove for architects, expanding your view and depth. We share enterprise, business, application, data, technology, and security architecture, discuss frameworks, planning, governance, standards, and implementation, and explore emerging styles such as microservices, event‑driven, micro‑frontend, big data, data warehousing, IoT, and AI architecture.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.