In Business Process Model and Notation (BPMN) terminology, a ‘Swimlane’ contains primary grouping BPMN elements: Pools and Lanes. Correctly designing a BPMN swimlane diagram requires a clear understanding of the two:
Pools
‘Pools represent’ essential BPMN elements that set the boundaries of a business process. A BPMN pool will contain, at most, one business process. This means that two processes have to be modelled 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 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).
‘Black-box’ pools are commonly named after the corresponding organization, person, or system (e.g., ‘supplier’, ‘customer’, or ‘content management system’).
Lanes
A BPMN ‘lane’ is a sub-partition within a pool used to organize and categorize process activities. A lane commonly represents an organizational role (e.g., ‘developer’, ‘analyst’, or ‘manager’). However, lanes may also be used for other purposes (e.g., the first, second, and third phases).
Common Misunderstandings
The meaning and semantics of BPMN pools and lanes are often misunderstood. For example, a set of pools can be incorrectly treated as a set of lanes within a single pool or vice versa. Some users may even focus on BPMN pools and swimlanes without delving into the terminology, leaving them with only vague basics that will leave them without the benefits of the BPMN modelling language. This negligence leads to syntactically and semantically wrong process models.
Because of the semantic differences between pools and lanes, the BPMN diagram flow elements (‘activities’, ‘gateways’, and ‘events’) will connect differently depending on whether they are used within or between pools.
Within a pool, BPMN flow elements are connected with sequence flows in the following ways (presented in Figure 2):
Only 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:
Note that in the previous two Figures, the connections are allowed only between elements. Based on these misconceptions, the following three mistakes are common when modelling BPMN 2.0 swimlanes:
Mistake 1: Missing Sequence Flows
Problem. When modelling multiple pools (e.g., in business-to-business situations where two or more processes interact), a common mistake is when a pool’s activities are not connected to its sequence flows.
The most frequent reason for this mistake is that a modeller may treat multiple pools as a single process and incorrectly interpret message flows as being used to indicate a sequence of activities. This process model is invalid because the sequence of activities has not been clearly defined.
Solution. The modeller should always model and validate individual pools and remember 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 demonstrated in Figure 2 and Figure 3. You can observe the incorrect and correct ways of inserting sequence flows in the BPMN swimlane examples seen in Figure 4 and Figure 5.
Mistake 2: Incorrect Usage of Sequence Flows
Problem. Another common concern when modelling multiple pools is that a modeller may treat a set of pools as a single pool with multiple lanes. In this case, a modeller uses sequence flows between pools. The result will be an incorrect model (see Figure 2) of a single process that spreads over the pool’s boundaries.
Solution. 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.
Mistake 3: Improper use of Lanes
Problem. Sometimes a modeller may incorrectly treat a lane as a pool, representing individual processes within separated lanes. This is wrong because a lane is just an ‘activity-classifying mechanism’.
Figure 8 shows this mistake:
Solution: The most common solution to this problem is similar to the previous one: define a single process out of two (shown in Figure 9). The redundant start and end events can be removed from the model. In the case that several pools are required (i.e., several independent processes exist), the solution to Mistake 1 should be used.
Nevertheless, it is essential to mention that it is not syntactically wrong if a single process has two start or end events! For example, different events could start a process in different places, such as an asynchronous process through a message trigger or the periodical start of a process every morning. On the other hand, it is common for a process to end at different end states (e.g., ‘successful treatment’ or ‘unsuccessful treatment’).
Conclusions
This article introduced the concept of BPMN ‘swimlanes’, which are modelled with ‘pools’ and ‘lanes’. At a glance, both elements look very similar. However, they have entirely different meanings!
A ‘pool’ is a container for a single process, whereas a ‘lane’ acts as an activity-classifying mechanism. Based on these differences, how 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.
