Pools and Lanes in BPMN: Clearly Defining Responsibilities

In a BPMN diagram, Pools and Lanes are essential visual elements used to define who does what. More than simple layout tools, they help structure processes clearly, showing roles, departments, organizations, or systems involved in execution.

A pool always represents a participant in the process — someone or something that executes or collaborates in the process, such as a company, a department, or a system. This visual separation helps clarify how participants interact through message exchanges and clearly defined responsibilities.

What Is a Pool?

To begin structuring a BPMN process, you first need to identify who is involved. A pool is the element that represents each participant — whether it’s a company, department, or system — that plays a role in the process.

A pool can represent:

• An organization (e.g., "Supplier")
• A department (for collaborative internal processes)
• A system (such as “ERP” or “CRM”)

In collaborative process models, each pool shows which participant performs which part of the process, and how they exchange information via message flows.

What Are Lanes?

After identifying the participants, the next step is understanding how responsibilities are divided within each one. That’s where lanes come in: they are internal subdivisions within a pool that show who is responsible for each task.

Lanes divide a pool into roles, departments, or functions within the participant.

• They help assign responsibility to each task.
• They show collaboration across areas.
• They do not contain logic — they are simply visual organizers.

Sequence Flow vs. Message Flow

When modeling processes with multiple participants (represented by pools), it's essential to understand how tasks are connected. Not every connection is the same — there’s a clear difference between internal flows, which show the order of activities within one participant, and message flows, which show communication between different participants.

• Sequence Flow (solid arrows): connects activities within the same pool, showing the order of execution.

• Message Flow (dashed lines): connects activities between different pools, indicating information exchange or coordination.

How to Handle Messages Between Pools

In BPMN, communication between different participants (represented by separate pools) must always be done using message flows — not sequence flows. To represent this correctly, you can use specific task types and message events designed for this purpose.

Here are the main elements you can use:

Send Task

A Send Task is used when the process needs to send a message to another pool. It visually shows that the task’s primary purpose is to dispatch a message to a participant.

💡 Example: After validating a termination request, a Send Task can be used to notify the IT department.

Receive Task

A Receive Task is used when the process is waiting to receive a specific message from another pool before continuing. It represents an explicit waiting point for incoming communication.

💡 Example: The IT team may use a Receive Task to wait for a formal request to revoke access.

Intermediate Message Events

You can also use Intermediate Message Events to model more flexible communication points.

• Throwing Message Event (Send): used to send a message mid-process.
• Catching Message Event (Receive): used to wait for a message before continuing the flow.

These are useful when the message is not the main goal of the task, but part of a larger activity.

💡 Example: A catching message event can be placed before an approval task that should only begin once an external confirmation is received.

Start Message Event

If a process is triggered by a message from another participant, you can use a Start Message Event at the beginning of that process.

💡 Example: The “IT System Access Management” process may start with a Message Start Event when it receives a request from the HR process.

Using the correct combination of message tasks and events helps make the process flow more accurate, maintainable, and ready for automation — especially when systems or external partners are involved.

Message End Event

A Message End Event is used when a process ends by sending a message to another participant. It represents the final point of the process, where a message is dispatched — often to notify another team or trigger a follow-up process.

• It is visually similar to other end events, but marked with an envelope symbol.
• Commonly used in subprocesses or supporting processes that must report back to the main flow.

💡 Example: After completing the debt verification, the financial process ends with a Message End Event that notifies the HR team, allowing them to proceed with final steps.

Practical Example: Termination of Employment

Let’s now explore a BPMN example to reinforce what we’ve learned — this time using the Termination of Employment process.

This is a common real-world scenario that requires coordination across multiple teams — such as HR, direct managers, and the IT department — to ensure that all steps are completed securely, consistently, and in the correct order.

In this example, we focus on how to use message flows between pools to:

• Initiate processes in other teams
• Keep the main process loosely coupled while maintaining coordination
• Transition tasks between lanes to reflect role-based responsibility changes

Let’s begin by analyzing the flows highlighted in the image below.

Arrow A shows a sequence flow connecting two tasks within the same pool. As the Termination of Employment process moves from "Complete Termination Documentation" to "Validate the Termination Request", the responsibility shifts between lanes, representing different roles within the organization.

Also, arrow B illustrates a message flow. Here, the main process sends a message to the IT System Access Management team, initiating a separate process to revoke system access. This subprocess runs independently — the main termination process does not wait for its completion.

Now, let’s examine how the process interacts with the third pool.

Arrow C represents a message triggered by the intermediate event “Outstanding Debts Notification” and received by the start event “Employee Termination Processed” in the third pool. This pool contains a single task, and upon completion, it reaches the end event “Debt Verification Completed,” which in turn sends another message — represented by Arrow D.

Meanwhile, in the calling pool, the HR user can execute the task “Cancel Benefits and Deductions” in parallel with the third pool's process. However, the flow must pause at “Receive Financial Verification Message” to await the financial team's confirmation.

This blocking behavior ensures that no termination process can be finalized without debt verification from the finance team.

This complete process is part of our example database and is available for free to all HEFLO users. 👉 Click the button below to create a free HEFLO account and explore this BPMN diagram in full, directly in the modeler.

Types of Pool: Black Box and White Box

Sometimes, you don’t need or want to show what happens inside every participant. That’s why BPMN allows you to represent a pool in two ways, depending on how much internal detail you want to display.

1. Black Box Pool

A black box pool is used when you don’t show the internal process of the participant. It appears in the diagram, but contains no visible tasks.

• Represents an external party to whom you send or receive messages.
• Common for customers, suppliers, partners, or third-party systems.
• Helps keep the focus on what’s relevant to the process being modeled.

The image below illustrates a good example of a Black Box pool. The event "Acquisition of Goods Triggered" sends a message and waits for a response. Since the "Purchase Process" represents an external process, what happens inside it is not shown — and from the main process perspective, it doesn’t matter.

2. White Box Pool

A white box pool shows the internal activities of the participant.

• Used when you want to model the process inside the participant.
• Can be subdivided into lanes to show roles or departments.
• Lets you trace the entire sequence flow within the organization.

The "Termination of Employment" example above is a clear case of a White Box pool, as it displays all internal tasks and their execution flow.

✅ Best Practices

Now that you understand pools, lanes, and flow types, here are some best practices to help you use these elements effectively and keep your diagram clear, accurate, and ready for execution or documentation.

• Use separate pools for distinct participants.
• Use lanes to clearly define responsibilities within a pool.
• Never connect pools with Sequence Flow — always use Message Flow.
• Name pools and lanes clearly using terms your organization understands.
• Avoid naming lanes after individuals. Use roles or functions (e.g., “Purchasing Analyst” or “Finance Manager”) so the process remains valid even if the team changes.

💡 Good examples of lane names: “HR,” “Finance,” “Requester’s Manager”
❌ Avoid: “John Smith,” “Ana Pereira”

🎥 Free Video Lesson: Modeling a Pool with Two Lanes

Want to see all of this in action?

We’ve recorded a free video lesson that walks you step by step through building a BPMN process using a single pool with two lanes. It’s the perfect way to understand how to model internal responsibilities within one participant.

In this video, you’ll learn:

• How to create a pool and add lanes for different roles or departments
• How to correctly place tasks in each lane
• How to connect tasks using Sequence Flows within the same pool
• And best layout practices to keep your diagram clean and professional

Watch on

Frequently Asked Questions

Even with the concepts clearly explained, some questions are common — especially for those new to BPMN. Here are answers to the most frequent doubts:

Can I use lanes in different pools?

Yes. Each pool can have its own set of lanes to represent internal roles or departments. However, message flows should only connect elements between pools, never between lanes in different pools.

Can I connect tasks between pools using sequence flows?

No. Sequence flows must stay within the same pool. To connect different pools, always use message flows — they represent communication between participants.

Can lanes be nested or hierarchical?

No. All lanes within a pool are at the same level. BPMN does not support nested or indented lanes.

Should I name lanes after people?

Not recommended. Always use roles, departments, or job titles. Avoid personal names so your diagram remains valid over time, even if team members change.

When should I use a Send Task vs. a Message End Event?

Use a Send Task when sending a message is part of a process, usually followed by more tasks. Use a Message End Event when the process ends by sending a message — for example, notifying another team that a task is complete.

What’s the difference between a Receive Task and a Catch Message Event?

Both wait for a message, but a Receive Task is treated as a full task (can be assigned, tracked, etc.), while a Catch Message Event is more lightweight and often used for control or decision points.

How do I start a process when a message is received?

Use a Message Start Event. It triggers the beginning of a process when a specific message arrives — common in processes that depend on external requests.

What if I have multiple teams working in parallel?

Use parallel gateways inside a pool, or trigger multiple message flows to different pools. Synchronize them with a receiving message event or join gateway later, depending on your logic.

Conclusion

Understanding how to define participants and responsibilities using pools and lanes is key to creating BPMN diagrams that are clear, collaborative, and ready for improvement or automation. Pools and lanes make your process easy to read and aligned with how your organization really works.