BPMN Swimlanes

In BPMN terminology a “Swimlane” represents both primary grouping BPMN elements – Pools and Lanes.


A pool is a basic BPMN element that sets the boundaries of a business process. A pool will contain at most one business process. This means that two processes have to be modeled in two different pools. A pool may have visible internal details in the form of a process that will be executed (called a “White-box Pool”), or a pool may have no visible internal details (called a “Black-box Pool”). The type of pool that should be used will depend on the level of detail needed and the specific context.

“White-box” pools are most commonly named after the corresponding business process (e.g. “requirement management process”, “help-desk process” or “service delivery process”), whereas “Black-box” pools are commonly named after the corresponding organization, person or system (e.g. “supplier”, “customer” or “content management system”).


A Lane is a sub-partition within a pool and is used to organize and categorize activities of a process. Most commonly, a lane represents an organizational role (e.g. developer, analyst and manager). However, lanes may also be used for other purposes (e.g. first phase, second phase and third phase)

diagram-1Common Misunderstandings

The meaning and semantics of Pools and Lanes are commonly misunderstood. For example, a set of pools can be incorrectly treated as a set of lanes within a single pool or vice versa. This leads to syntactically and semantically wrong process models.

Because of the semantic differences between pools and lanes, the BPMN flow elements (activities, gateways and events) are connected differently depending on whether they are used within a pool or between pools. Within a pool, BPMN flow elements are connected with sequence flows in the following ways, presented in Figure 2.

diagram-2Only message flows can be used when communicating “between-pools”. Message flows indicate the exchange of messages between two pools or processes, including their synchronization. Message flows can be used as defined in figure 3:

diagram-3Note that in both cases the connections are allowed only between elements, as represented in the previous two figures. Based on these misconceptions, the following three mistakes are common when modeling BPMN:

Mistake 1: Missing Sequence Flows

Problem. When modeling multiple pools (e.g. in business-to-business situations, where two or more processes interact), a common mistake is when activities in a Pool are not connected to sequence flows.

The most frequent reason for this mistake is that a modeler may treat multiple pools as a single process and incorrectly interpret messages flows as way of indicating a sequence of activities. This kind of process model  is not valid because the sequence of activities  has not been clearly defined.

diagram-4Solution. The modeler should always model and validate individual pools,  and bear in mind that a pool cannot contain more than  one process. This means that all flow elements in a pool should be connected using sequence flows as defined in figure 2 and figure 3.

diagram-5Mistake 2: Incorrect Usage of Sequence Flows

Problem. Another common problem when modeling multiple pools is that a modeler may treat a set of pools as a single pool with multiple lanes. In this case, a modeler uses sequence flows between pools. The end result will be an incorrect model (see figure 2) of a single process that spreads over the boundaries of the pool.

diagram-6Solution. The most common solution to this problem is to exchange pools with Lanes within a single model, as presented below. If several pools need to be used (perhaps when several independent processes exist), the solution to Mistake 1 should be used.

diagram-7Mistake 3: Improper use of Lanes

Problem. Sometimes a modeler  may incorrectly treat a lane as a pool, thereby representing individual processes within separated  lanes. This is wrong, because a lane is just a “activity-classifying mechanism”. The figure below shows this mistake.

diagram-8Solution. The most common solution to this problem is similar to the previous one; define a single process out of two (shown in Figure 9).  This means that the redundant start and end events are removed from the model. In the case that several pools are actually required (several independent processes exist), the solution to Mistake 1 should be used.

diagram-9Nevertheless it is important to mention that it is not syntactically wrong if a single process has two start or two end events! For example, several different events could start a process in different places, for instance; an asynchronous start of a process through a message trigger, or the periodical start of a process every morning. On the other hand, it is common that a process ends at different end states (e.g. “successful treatment” or “unsuccessful treatment”).


This article introduced the concept of BPMN “swimlanes”, which can be modeled with “pools” and “lanes”. At a glance, both elements look very similar, however, they have completely different meanings!

A pool is a container for a single process, whereas a lane acts as an “activity-classifying mechanism”. Based on these differences, the way in which BPMN Flow elements are interrelated differs completely. In the case of between-pools interactions, only message flows can be used. On the other hand, only sequence flows can be used within a pool and between lanes.

Spot the Mistake: Descriptive Level Of BPMN - Interactive Quiz
Gregor received his PhD in 2008 in the fields of software engineering and information systems and has nearly a decade of experience in BPMN, starting to investigate and actively use BPMN since its introduction in 2004. In addition, he has participated in the development of one of the first BPMN modeling utilities - a package of plugins for Visio, which were introduced early in 2005 and is the main author of the first BPMN poster (bpmn.itposter.net), which has been translated into several languages and already exceeded 50.000 downloads.