Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Limited Usability of BPMN Lanes

Lanes (known as swimlanes in BPMN 1.x) represent process performers in BPMN.

Rules for the lanes:

  1. Lanes are optional.
  2. Lanes may be nested (hierarchical).
  3. Lanes semantics is fully at the discretion of the diagram’s author - it may be a function, role, position…
  4. Embedded subprocesses do not have pools and therefore can’t have lanes.
  5. Lanes are meaningful only to the user tasks - service tasks, script tasks, subprocesses, gateways, events are irrelevant to which lane you put them in.
  6. Even for the user tasks the lane is essentially a comment - actual performer is defined by the model attributes of the given task.

Novice BPMN users love lanes and use them at first excercises with enthusiasm:

Figure 1. BPMN diagram with lanes.

However using lanes won’t allow showing the process “happy path” which arguably is more valuable from ease of perception standpoint:

Figure 2. BPMN diagram with a happy path.

Moreover, when dealing with large processes there is no room for lanes at all.

There is a general rule applicable to any notation including BPMN: the number of activities at any diagram level should not exceed 7-9. Otherwise the scheme becomes too difficult to perceive:

Figure 3. “Flat” diagram with a large number of activities is hard to understand.

Accordingly, if the process comprises a large number of tasks, it should be decomposed into subprocesses:

Figure 4. Subprocesses help creating a simple diagram from a complex process.

But this style of modeling leaves no room for lanes:

  • At the top level there are only subprocesses while lanes apply only to the user tasks (rule 5).
  • Subprocess diagram doesn’t allow pools nor lanes (rule 4).

More precisely, rule 4 applies only to the embedded processes; reusable subprocesses may have lanes. I’ve seen diagrams where reusable subprocesses where used instead of embedded solely to be able to depict lanes. This is definitely bad practice - embedded subprocesses shall be used for the decomposition. Reusable subprocesses introduce additional complexity because unlike embedded they are executed in a separate data context.

If you can’t live without diagramming performers then use BPMN artifact “group”:

Figure 5. BPMN groups shows performers within the embedded subprocess.

06/27/11 | Articles | ,    

Comments (32)

  1. Ivo Velitchkov 06/27/11 03:34 PM

    Great article, Anatoly!

    Here you touched on one issue that I meet almost every day. The fact that lanes cannot be included in sub-process (unless they are global) frustrates many process analysts that don’t fully understand the logic behind BPMN rules. And that becomes especially hot when they move from a drawing tool to a real modelling tool that does not allow and/or alerts on semantic errors. But probably lanes come as frustration number two or three. Number one in my experience is the inability to have message flows reaching nodes inside sub-processes. Or at least that’s the thing I spent most time explaining. The absolute dependency (data- and control-wise) of the sub-process on its parent seems very difficult for many people to understand. Should we ask them to try harder or maybe it’s time BPMN got friendlier to their needs without losing its execution capabilities.

    Kind regards,


  2. Anatoly Belychook 06/27/11 04:09 PM

    Interesting thought, Ivo. I don’t see any particular logic in forbidding swimlanes in subprocesses, too. OK, there is one reason but it’s pure technical: no pool therefore no swimlanes. Guess they could find a workaround.

  3. Ирина 06/27/11 07:37 PM

    Вы говорите, что семантика дорожек может быть любой, таким образом, описывайте некий шаблон (полноценный стандарт), как нужно строить диаграммы бизнес-процессов.
    Как Вы считаете, возможно, ли создание стандартов выполнения бизнес-процессов в организации, не с точки зрения конкретики (например, заказ должен быть оплачен в течение трех дней), а с точки зрения выполнения бизнес-процесса как такового на концептуальном уровне (например, на схеме событий типа «сообщение» должно быть в количестве 5)? Это своего рода перерастает в некий стандарт, на который можно в последствии накладывать на конкретные данные (бизнес-процессы в организации). Спасибо

  4. Anatoly Belychook 06/27/11 08:38 PM


    Эффективное применение BPMN в организации требует выработки внутреннего стандарта по моделированию. Это необходимо из-за того, что BPMN позволяет моделировать одно и то же несколькими разными способами. В частности, в таком стандарте может быть сказано, что дорожками мы моделируем подразделения.

  5. Scott 06/28/11 05:15 PM

    Anatoly -

    would you say you’re arguing more for limiting the use of swim lanes, or limiting the use of re-usable subprocesses (if just for the purpose of getting swim lanes)?

    The way I read it (could be wrong) you’re not arguing one shouldn’t use swim lanes, just that the spec and the use of proper model decomposition make it hard to use swim lanes properly without using re-usable subprocesses… but I may be misreading.

  6. ian gotts 06/28/11 06:24 PM

    The issue with swimlanes is that they are a useful analytical device for identifying process improvement, but as this great article shows they make end user adoption very difficult. Why - the ability to lay out a swimlane makes the diagram too large to be easily displayed on a browser, iPad or smartphone. Printed and stuck on an office wall is no longer good enough with a mobile workforce.

  7. Anatoly Belychook 06/29/11 09:25 AM


    Well I didn’t mean to give recommendations, just to explain what can and what can’t be done with swimlanes. BPMN was intentionally desinged as methodology-neutral so there is no single truth there. But there are rules that confine modeler’s freedom and I just wanted to clarify them for novice BPMN users.

    My personal position is this: one can’t bring secondary aspects to the diagram without compromising primary things, i.e. making them less clear. For me, the control flow is primary and participants are secondary.

    So for really complex processes swimlanes are luxury we can’t afford; happy path style diagram are 1) more informative, 2) more compact as Ian noted and 3) are scalable in BPMN because unlike swimlane style diagrams they don’t suffer from process decomposition into subprocesses.

    BTW, I apply the same principles to data flows: there are data objects in BPMN but they are secondary with respect to control flow. Data objects/stores become primary issue only in interprocess communications, see

  8. Bruce Silver 07/07/11 04:57 PM

    While I disagree with some of your “rules” about lanes (#4 is incorrect, for example), I agree with the general points you make. I have noticed that people who really care about lanes, such as process improvement consultants, prefer the flat modeling style, as opposed to architects, who favor hierarchical modeling. If you care about handoffs between lanes in your process improvement methodology, flat models work better. I have had a difficult time using lanes effectively in my Method and Style approach, which favors the hierarchical style.

  9. Anatoly Belychook 07/07/11 05:50 PM


    Thank you for the valuable input.

    Regarding #4 “Embedded subprocesses do not have pools and therefore can’t have lanes” - which part of it is incorrect?

    - Is it possible to draw a pool on embedded subprocess diagram (apart from external entities and processes others than the one the subprocess belong to)? I’t be very confusing: we already used the pool for the top-level process.

    - Is it possible to draw lanes without pools on embedded subprocess diagram? The spec (p.282) says “A Lane is a sub-partition within a Pool or a Process”. It’s hard to imagine lanes without a pool.

  10. Szymon Drejewicz 07/10/11 10:45 PM

    Lanes are sub-partitions within a Pool or a Process. However, you are allowed to remove the boundary of at most one Pool (participant) in Collaboration. So, for me that impies that I can use lanes without a pool. So I can use it within a subprocess as well. Anyway I am not sure is that a real problem. I need lanes only when I need to stress that there is a “more” complicated “structure” of an organisation involved in process.

  11. Anatoly Belychook 07/18/11 11:25 AM


    You are probably right but it raises a question about the quality of BPMN spec: better have it explicit rather than guessing of what’s implied. At the end of the day each vendor would follow its own judgement.

    It’s not a real problem for you neither for me but it is for many people as comments above witness.

  12. Илья Логинов 05/18/12 02:42 AM

    Как раз расположение подпроцесса на дорожке очень удобно - видно ответственное лицо за контроль исполнения подпроцесса, которое вправе изменить структуру подпроцесса по ходу выполнения экземпляра в случае если это не изменит результат на выходе из подпроцесса в худшую сторону (например вмешаться в подпроцесс нарушить его форсмажорно и тем самым ускорить выполнение подпроцесса). Важная роль дорожек для подпроцессов неоднократно раскрывалась разработчиками стандарта. Поэтому странно, что дорожкам нет места где подпроцессы или может я вас не так понял.

  13. Anatoly Belychook 05/18/12 03:04 PM


    А ведь Вы правы: стандарт говорит, что дорожки имеют смысл для активностей, т.е. и для подпроцессов тоже.

    Стал разбираться с чего я взял, что дорожки имеют смысл только для user task - по-видимому, из книги Брюса Силвера “BPMN Method & Style”, стр. 36: “Lanes usually just make sense for human task”. Но он фактически говорит о стиля, а у меня он трансформировался в правило.

    Спасибо за находку.

  14. David Morris 09/12/12 10:34 PM

    Nice summation of the principle concerns and some enthusiastic contributions … the crux seems to be the following:

    “Regarding #4 “Embedded subprocesses do not have pools and therefore can’t have lanes” - which part of it is incorrect?”

    I think this is based on an over-zealous interpretation of the BPMN specification by the tool developers; in other words, while it is true that the sub-process cannot have a pool, the BPMN specification does not specify that the sub-process cannot have (swim)lanes.

    Here’s why I think lanes in sub-processes should be permitted:

    1) Implicitly a sub-process has a pool, because it is in a pool and inherits attributes of its parent.
    2) Therefore, everything within a sub-process must logically take place in its parent lane.
    3) As there are no theoretical limits to nesting lanes.
    4) Therefore, a sub-process should be able to have lanes, so long as those lanes are semantically nested within the parent lane.

    An example of this might be a lane for a warehouse and a sub-process for order picking. Within the sub-process, we should be able to have lanes that represent various direct operational responsibilities (e.g. fork-lift, aisle pickers, consignment packers, etc.), as well as any appropriate management and support responsibilities (e.g. warehouse administration, damaged goods bay, etc.).

  15. Anatoly Belychook 09/13/12 09:34 AM


    You are absolutely right and my initital statement is wrong - I admitted it already in the previos in comment but it’s in Russian.

    The standard is bit vague on this but there is no direct prohibition.

    I also agree that it’s an overlook of some tool developers. Swimlanes in subprocesses are undoubtedly useful and should be enabled.

  16. Cristian 12/05/13 08:38 PM


    Then the approach that makes most sense to me is to use no lane in parent process and use lanes freely in subprocesses. I just worked in a process and because I did want lanes in parent process because of the complex structure of organization, I started to find out that my process decompozition became too driven by lanes, because sometimes a subprocess tended to spend multiple parent lanes, so I had to break subprocesses just to have lane-homogenous sub-subprocesses. But by using my initial statement of this post, it seems to me this way one gets the best of both worlds. Am I missing anything here?

  17. Anatoly Belychook 12/05/13 08:55 PM

    Cristian, you’ve got the point.

  18. Cristian 12/05/13 09:00 PM

    Anyway, your idea with groups works nicely as well. Does Bizagi allow lanes in a subprocess these days? I read your request on their forum some time ago…

  19. Anatoly Belychook 12/05/13 09:04 PM

    I’m afraid not yet. Have to utilize reusable subprocesses just for this.

  20. Cristian 12/05/13 09:05 PM

    The difference is groups are visible always in parent process, while lanes are only visible in expanded subprocess, so subprocesses encapsulate the performer info.

  21. Cristian 12/05/13 09:06 PM

    Oh :( i was hoping they do…

  22. Cristian 12/05/13 09:07 PM

    Then groups come to the rescue. I remember you try to do bpm with bpmn the way it is, not as it will possibly become. So groups are the option for now.

  23. Cristian 12/05/13 09:18 PM

    Sorry, silly me…groups may also be encapsulated, more like a pseudo-lane in subprocess. Actually nothing gets lost with groups, at all, I think. I find this approach better than using callable activities as a workaround. Really…

  24. Cristian 12/05/13 09:20 PM

    One can even draw the lanes as groups, themselves.

  25. Steve 09/24/14 12:18 PM


    As I understand the specification, lanes can be nested. Why, then, cannot the decomposition of a lane be shown in a sub-process?

    There would need to be certain caveats to this. For example, that the lanes do not already appear at a higher level of the hierarchy in the process set. I am sure there are others…

    I welcome your thoughts.


  26. Anatoly Belychook 09/25/14 08:11 AM


    For me, subprocesses are the way to introduce levels of abstractions. The less top-level diagram “knows” about internal structure of a subprocess the better. From this perspective we shouldn’t make suggestions about what lanes may be needed to depict subprocess activities and hence we would be unable to define the common root lane.

    Besides, they very likely would not have such a common root except the company as a whole.

    Yet there is another idea to combine subprocesses and lanes: to depict the unit *responsible* for the subprocess, not the performer(s). In case of a task they are the same, in case of a subprocess there are many performers yet very well may be a single responsible/coordinating business unit or role.

    How do you like this?

  27. Edmund Sulzanok 12/01/14 05:31 PM

    “A Lane is a sub-partition within a Pool or a Process”… There’s “or” for a reason. Pools are optional if you’re drawing a single process. But if there’s two or more processes interacting you need to destinguish one from another. In this case do you need to put both processes in pools? The notation doesn’t specify, so it isn’t forbidden. IMO the drawing area is implied as the process, where you can use lanes without pools.

    My guess is that sub processes are just as much activities as tasks. And it matters in which lane task is positioned. Sao maybe lanes in subprocesses are not allowed because, if you used lanes in you top level diagram and your collapsed subproces is in “sales” lane, all of it’s tasks be done by “sales” not “production.” If that is the case, BPMN 3.0 should state that subprocess is process not activity and it doesn’t matter in which lane subprocess is positioned (same as events and gatways).

    Or maybe it is because collapsed and expanded subproceses should be interchangeable, but lanes in expanded subprocesses are nonsense (visually). In this case they should just dump expanded subprocesses from notation. I mean — DOES ANYONE USE THEM AT ALL???

  28. Anatoly Belychook 12/01/14 05:56 PM


    If there are more than one processes on the diagram then you may draw just one of them without the pool - the canvas becomes the pool. There are enough such examples in the spec.

    Lanes in the subprocesses are allowed but your remark about performer is valid and should be addressed. Here is how I personally approach this today, three years after the posting.

    Let’s separate performers - people who actually do the work and assgnee - human, entity or role responsible for the work to be done. In case of atomic activity i.e. task they are the same. In case of a subprocess the lane specifies assignee but not necessarily a performer - there may be several performers and hense lanes at the next level of details.

    Does anyone use the lanes - from my observations yes, most of people do.

  29. Edmund Sulzanok 12/01/14 06:17 PM

    I was asking if anyone is using expanded subprocesses? I’m not, are you?

  30. Anatoly Belychook 12/01/14 06:34 PM

    Sorry, didn’t get you right.

    There are two use cases for subprocesses:

    1) Process decomposition. The best practice for these are collapsed subprocesses I believe.

    2) “Technical subprocess” to implement certain workflow pattern. For example, non-interruptive attached events behaviour can be implemented with a subprocess within BPMN 1.x palette. In this case expanded subprocesses may be useful.

  31. Алексей 09/15/16 11:59 PM

    Анатолий, здравствуйте!

    Как сейчас обстоят дела в Bizagi с возможностью использовать дорожки внутри подпроцессов? Ранее (год назад примерно), как я помню, это было затруднительно.

    Постараюсь объяснить:

    Допустим, мы имеем некий сквозной процесс “от звонка клиента до доставки клиенту”, который мы моделируем “на самом верхнем уровне” как два пула: “клиент” как черный ящик и сам наш процесс; процесс (happy way) показываем в пуле развернуто и совсем крупно как последовательность, например, десяти подпроцессов, реализуем (указываем) межпроцессные взаимодействия.

    Далее мы хотим начать “углубляться” (структурно декомпозировать подпроцессы до уровня исполнителей/ролей). Например, моделируем первый подпроцесс “обработка входящего звонка” (если клиент звонит первый раз, если второй раз, если новый клиент, если не новый, если постоянный ну и так далее), который подразумевает при его исполнении подключение разных ролей (в простых случаях Марина (операторы), в средних - саентолог Коля (отдела кирбистов, на разных этапах) и в тяжёлых - Михалпетрович (подразделения гипноза и зомбирования). То есть имеется некое интуитивное желание/необходимость разделить роли и описать подпроцесс “по ролям”, используя пул и для каждой роли дорожки. Архитектура процессов в таком случае видится как “пирамида процессов” - набор от вершины к основанию.

    Имеет место быть такая практика описания “от общего к частному” при моделировании/описании неисполняемых процессов? Или такая логика описания процессов ущербна (допустим, что все задачи процесса синхронны [пусть workflow для примера])? Извините за легкомысленный стиль изложения - я надеюсь, мне удалось выразить суть вопроса.

  32. Anatoly Belychook 09/16/16 08:36 AM

    Такая практика не только имеет место, но является рекомендуемой.

    Что касается дорожек в моделере, то проблема такая есть, но обходится она легко: используйте повторно-используемые подпроцессы.

Comments are closed

Copyright © 2008-2024 Anatoly Belychook. Thanks to Wordpress and Yahoo.  Content  Comments