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 represent’ basic 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 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’).
‘Black-box’ pools are commonly named after the corresponding organization, person, or system (e.g., ‘supplier’, ‘customer’, or ‘content management system’).
A BPMN ‘lane’ is a sub-partition within a pool used to organize and categorize activities of a process. Most commonly, a lane represents an organizational role (e.g., ‘developer’, ‘analyst’, or ‘manager’). However, lanes may also be used for other purposes (e.g., the first phase, second phase, and third phase).
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 full benefits of the BPMN modeling language. Needless to say, 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 a pool 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 modeling BPMN 2.0 swimlanes:
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 a pool’s activities are not connected to its 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 being used for indicating a sequence of activities. This kind of process model is not valid because the sequence of activities has not been clearly defined.
Solution. 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 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 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.
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.
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 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). This means that the redundant start and end events can be removed from the model. In the case that several pools are actually required (i.e., several independent processes exist), the solution to Mistake 1 should be used.
Nevertheless, it is important 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 start of a 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’).
This article introduced the concept of BPMN ‘swimlanes’, which are 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.