BPMN in practice – pools and lanes

Are you using BPMN? If so, chances are that you may be making one of the common BPMN errors which happen not only to modeling newbies but also long time modelers.

In this post I will show you how to use pools and lanes properly and how to avoid common errors. In the following posts you will learn about other problematic areas of BPMN.

You should remember the following things:
1) Pools represent the process participants (i.e. they answer the WHO question, while process steps answer the WHAT).

They are rectangles with a label (and dividing line).




Now the fun part: pools can be organizations or units – it depends on your perspective. And this lack of clear rule is first source of problems for BPMN modelers 🙂

However in practice you can overcome this by remembering that participant has full control over the process inside a pool. Generally speaking it means that usually you will have one pool representing your whole organization (assuming there is some end-to-end handling of a process…) and other pools will represent other participants such as your customers, partners etc.

Fun fact: you do not need to draw a pool for the main process participant. It is treated as implicit. In practice it is helpful if you are creating a very simple diagram or do not worry about using lanes to show responsibilities (because your tool supports e.g. RACI as it is in ADONIS).

2. To show that certain units/roles are responsible for performing specific process steps you can divide the process with lanes (rectangles within a pool).






Does it always work like this? Nope…
Sometimes it may make sense to have more pools, where each of the pools shows part of the end-to-end process (e.g. parts done in HR, IT etc). This approach is pretty common in cases where you do not care very much about seeing the process as a whole and want to be able to present process parts to the different user groups (e.g. your colleagues from IT may not be very interested about details of work done by HR in the new employee onboarding process). It may also make sense if you want to automate only some parts of the whole process – in this case one pool could cover elements done by the BPMS engine.

Now we approach second problem – what is the difference between process flow within a pool and communication between pools?

Let’s assume you identified all the process participants and created pools and lanes as needed. How should you show the flow of your process?

3. To connect elements of the process (events, tasks, sub-processes, gateways) you need to use sequence flows – arrows with solid line and filled arrowhead:



Please remember that each pool needs to be either empty (it is so called black box pool serving as placeholder to show that we have a participant but do not need to document details of her process) or complete.

In practice it means that you cannot have interrupted process flows in a pool or processes that do not start and end properly.

4. Just like you cannot swim outside your swimming pool, you cannot have sequence flow that traverses pool boundary (however you can dive to change lane within a pool).

5. To represent details of collaboration (i.e. how do they exchange messages) between participants you should use Message Flows. Those are arrows drawn with dashed line.



6. Message Flows are only allowed between the pools. You cannot have message flow inside a pool.


Now let’s take a look at a few diagrams showing those errors in practice.

Diagram A.
You can see here two types of errors marked with red “!”. First: sequence flow crosses the pool boundary. Second: none of the pools contains a complete process (e.g. first pool lacks end event).

In order to make this diagram valid we would need to change first two pools to lanes (since both are one company) and add a higher level pool (calling it e.g. ACME Corp). Now we would need to decide how to make the pools show proper content. The simplest way would be to add end event to the first pool and treat customer as black box pool (since we do not really care how does the customer order as long as we receive the order, send the ordered items and – in a following process – handle the payment).

Diagram B.
Let’s return to the original diagram and assume we wanted to complete the customer pool.
As you can see on a diagram above we are missing sequence flow between “Order the widget” and “Pay for the order”. In practice it would mean our (customer) process never completes. Fix is very easy – we would only need to add the sequence flow (of course afterwards it would make sense to adjust scope of the process since ACME corp does not handle the customer payment).

Now, let’s take a look at an example of a correct diagram with more sophisticated example (this is example taken from one of the BPMN Model Interchange Working Group test cases).
As you can see each of the pools is complete and communication between them uses message flows.

Do you want to learn more?
Below you can find video lecture from my Udemy course “BPMN for Business Analysts” where I cover topic of pools and lanes.

Did you enjoy the video? Join my course to learn more about BPMN

Yes! I want to learn more!

3 Comments for “BPMN in practice – pools and lanes”

Alex Aganov


I would consider to make the following changes to the example of the “correct” diagram above to be consistent with the approach used on Diagram B., and BPMN standards (BPMN doesn’t define an event as an activity, therefore it shouldn’t be named using active verbs):
(1) change the the following events’ names from:
“Receive Order” to “Order received”;
“Receive CC Information” to “CC information received”;
“Send Result” – “Result sent”, etc.
(2) for the sake of consistency, insert proper names under each unnamed event.



Totally agree Alex 🙂 However I was simply showing example of a diagram from MIWG demo, so I cannot adjust names as in my examples.

Leave a Reply

Your email address will not be published. Required fields are marked *