Lane
A subdivision inside a Pool that organizes activities by role, department or system. Sequence flows cross lanes freely — lanes assign responsibility, not communication boundaries.
Lanes answer *who does what* within one participant: the Agent registers, the Manager approves. Crossing a lane border is just a hand-off of responsibility — the token flows on ordinary sequence flows, no messages involved.
Lanes can nest (sub-lanes) for finer structures, though deep nesting quickly hurts readability.
When to use and avoid
When to use
To show role-based responsibility for each activity within one organization.
To expose hand-offs — often the first place to hunt for delays and rework.
When 'who does it' is a first-class question of the model.
When NOT to use
For independent participants exchanging messages — separate Pools.
When responsibility is uniform or irrelevant — laneless diagrams are cleaner.
As a systems-architecture map — lanes order responsibility, not deployment.
Business example
Agent and Manager lanes in one service desk
Open this example in the HEFLO process editor and explore the diagram from the inside.
Open in the HEFLO editor →Step by step
- The Service desk Pool splits into two Lanes (highlighted): Agent and Manager.
- Register request sits in the Agent lane; the flow then crosses — an ordinary sequence flow — into the Manager lane for Approve request.
- The lane crossing *is* the hand-off; no message needed inside the same Pool.
Differences
Lane vs Pool
Crossing a lane is a responsibility hand-off on plain sequence flow. Crossing a pool is inter-participant communication requiring message flows. Same org → lanes; different orgs/systems → pools.
FAQ
Do lanes affect execution semantics?
Not in the spec — they are organizational annotation. Engines usually map lanes to assignment roles, but that's an implementation convention.
Can a lane hold another lane?
Yes, nested lanes are allowed (e.g. department → teams). Keep nesting shallow for readability.