|We create visual process models in order to better understand, discuss and remember processes. Hence it is crucial that models are easy to read and to understand. The single most important thing is to to use well-chosen labels.|
|You must||You should||You may|
Use conventions for Naming BPMN Elements, this will consistently inform the reader of the business semantics. The clarity and meaning of a process is often as good as how well-chosen it’s labels are.
|1||A labeled start event informs reader of how the process is triggered.|
|2||An activity - labeled as "activity" - informs the reader of which piece of work needs to be carried out.|
|3||A labeled gateway makes it clear as to which condition(s) the process proceeds and on which sequence flow.|
|4||A labeled boundary event clearly expresses in which case the process might move along an exceptional path.|
|5||Labeled end events characterize end results of the process from a business perspective.|
Try to model symmetrically. Identify splitting and joining gateways "belonging" to each other and form easily recognizable visual, eventually nested, blocks with those gateways.
|1||The inclusive gateway splits the process flow into two paths which are …|
|2||… joined again with an inclusive gateway. Inside that block …|
|3||another exclusive gateway splits the process flow into two more paths which are …|
|4||… joined again with an exclusive gateway.|
|By explicitly showing pairs of gateways "opening" and "closing" parts of the process diagram, and by positioning such pairs of gateways as symmetrically as possible, your process model will become easily readable by allowing the eye of the reader to recognize logical parts of the diagram and quickly "jump" to those parts of the diagram the reader is momentarily interested in most.|
Model process diagrams from left to right. By carefully positioning symbols from left to right according to the typical point in time at which they happen you can further improve the readability of process models:
|Modeling from left to right supports the reading direction (for western audience) and supports the human field of vision - which prefers wide screens: 16:9 has established itself for a reason!|
Consciously decide whether overlapping sequence flows make your model more or less readable. On one hand avoid overlapping sequence flows when the reader will not be able to follow the flow directions anymore. On the other hand, use overlapping sequence flows in case it is less confusing for the reader to see just one line representing many separate sequence flows which lead to the same target.
Avoid sequence flows violating the reading direction: So no outgoing on left hand side of a symbol or incoming on the right hand side of a symbol.
|1||You could have made the five (!) sequence flows going into the end event made visible by separating them. However, by consciously choosing to partly overlap those flows, this model becomes visually less cluttered, and therefore less confusing and easier to read.|
|2||You could have attached the sequence flow going out of this task on its left hand side. However, experience shows this to be less readable, because the flow connection violates the reading direction. The same is true for flows incoming on the right hand side of a symbol.|
Avoid flows crossing each other and flows crossing many pools or lanes, wherever possible. Rearrange the order of lanes and paths to make your sequence flows more readable. Often it can even be a good idea to remove lanes in order to improve readability! Rearrange the order of pools in a collaboration diagram to avoid message flows crossing through other pools as much as possible. Often you will find a "natural" order of pools reflecting the order of first involvement of parties in the end-to-end process. This order will often also lead to a minimum of crossing lines!
Avoid modeling very long (multi page) sequence flows, especially when flowing against the reading direction, because the reader will loose any sense of what such lines actually mean. Instead use link events to connect points which are not on the same page/screen anymore.
|1||You see a throwing link event here, which …|
|2||… directly links to a catching link event just as if the sequence flow would have been connected.|
|Avoid to excessively use links events. The example above serves to show the possible usage of link events - at the same time it is too small to satisfy the usage of link events in real life!|
Make your models easier to understand by modeling explicitly, which most often means to either completely avoid certain more "implicit" BPMN constructs - or at least to use them cautiously. Always have in mind the central goal of increased readability and understandability of the model, when deciding whether to model explicitly or implicitly. When in doubt, best to favor an explicit style.
Model splitting the process flow by always using gateway symbols like instead of conditional flows
|1||You could have left out e.g. this inclusive gateway by drawing two outgoing sequence flows directly out of the preceding task "Choose menu" and attaching conditions to those then "conditional sequence flows" (). However, experience shows that readers understand the flow semantics of gateways better, which is why we do not make use of this possibility.|
Model the trigger and the end status of processes by always explicitly showing the start and end event symbols.
|1||According to the BPMN standard, you could have left out the start event …|
|2||… as long as you also leave out the end events of a process. However, you would have lost important information in your model, which is why we do not make use of this syntactical possibility.|
Be specific about the state you reached with your event from a business perspective. Quite typically you will reach "success" and "failure" like events from a business perspective:
|1||'Invoice paid' better qualifies the "successful" business state than e.g. 'Invoice processed' would …|
|2||… because in principle you can call the failed state 'Invoice processed', too, but the reader of the diagram is much better informed by calling it 'Invoice rejected'.|
In general, avoid mixing up the split and join semantics of gateways by explicitly showing two separate symbols:
|1||You could have modeled this join implicitly by leaving out the explicitly joining XOR gateway and directly connecting two incoming sequence flows to …|
|2||… the subsequent splitting XOR gateway. Of course, BPMN would allow this for other gateway types, too. However, experience shows that readers will often overlook the join semantics of such gateways serving two purposes at the same time.|
|The fact that readers will often overlook the join semantics of gateways serving to join as well as split the process flow at the same time, combined with the preference for modeling symmetrically leads us to prefer splitting and joining gateways modeled with separate symbols.|
However, there are cases in which the readability of models can be improved with implicit modeling. Consider the following example:
|1||The primary function of this gateway from a reader’s perspective is to split the process flow based on events. However, it is also joining two sequence flows. You could explicitly model that join by introducing a separate joining XOR gateway directly before the event based gateway. We argue that this will not increase readability, but rather decrease it.|
|A decrease in readability by modeling explicit joining gateways often happens when modeling loops, because many readers will be slightly irritated by a joining gateway which is visually placed before the splitting gateway "belonging" to the same block. It is then often preferable to just use implicit joining to avoid unnecessary irritations.|
Model the XOR gateway by explicitly showing the "X" symbol, even if some tools allow to draw a blank gateway.
|1||You could have shown the splitting gateway …|
|2||… as well as the joining gateway without the "X" symbol indicating that it is an exclusive gateway.|
|The "X" marker makes a clearer difference to the other gateway types (inclusive, parallel, event-based, complex) which leads us to prefer explicit XOR gateway markers in general.|
Always model splitting the process flow by explicitly showing the gateway symbol:
|1||You could have modeled this parallel split implicitly by leaving out the gateway and drawing two outgoing sequence flows out of the preceding task "Choose menu". However, the reader needs deeper BPMN knowledge in order to understand this model. Additionally for joining the parallel flows …|
|2||… you will always need the explicit symbol.|
|The fact that readers of models using parallelization will most probably need to understand the semantics of a parallel join combined with the preference for modeling symmetrically leads us to prefer explicit parallel gateways, too.|
Model joining the process flow by explicitly showing the XOR gateway symbol - so the reader does not have to know BPMN details to understand how two incoming or outgoing sequence flows in a task behave. Additionally this often supports the symmetry of the model by explicitly showing a "relationship" of the splitting and joining gateways forming a visual "block".
|1||You could have modeled this join implicitly by leaving out the gateway and directly connecting the two incoming sequence flows to the subsequent task "Have lunch". However, explicitly modeling the join better visualizes a block, the joining gateway semantically "belongs" to …|
|2||… the earlier split. In case the reader is not interested in the details of dinner preparation but just in having dinner, it’s easy to "jump" to the gateway "closing" that logical part of the model.|
This is particularly helpful for models bigger than that example with many such - eventually nested - blocks. Consider the following model, showing two nested blocks of gateways:
|1||Now, you could not even have modeled this join implicitly, because it’s directly followed by an inclusive gateway with very different join semantics. Consistency of joining techniques is another reason why we prefer explicitly joining sequence flows in general.|
There are always exceptions to the rule! There are cases in which the readability of models can be improved with implicit modeling.
So don’t be dogmatic about explicit modeling, always aim for the best readable model.
The following example shows a case of a model in which splitting and joining points do not form natural "blocks" anyway. In such cases, it can be preferable to make use of implicit joining to improve the overall readability!
|1||You could have modeled the implicit join happening at this task with an exclusive joining gateway. However, here one might decide that the implicit join contributes to readability.|
|2||Again, you could have modeled the implicit join explicitly, to. As this again would not visualize a simple "block" of gateways, we often prefer to leave it out.|
You may want to emphasize the "happy path" leading to the delivery of a successful process result by placing the tasks, events and gateways belonging to the happy path on a straight sequence flow in the center of your diagram - at least as much as possible.
The five BPMN symbols belonging to the happy path are put on a straight sequence flow in the center of the diagram.
Consider avoiding lanes for most of your models all together. They tend to conflict with several of the best practices presented here, like Modeling Symmetrically, Emphasizing the Happy Path and Creating Readable Sequence Flows. Apart from readability concerns, our experience also shows that lanes make it more difficult to change the resulting process models and therefore cause considerably more effort in maintenance.
|When modeling on an operational level, where showing the responsibility of roles matters most, we recommend to use collaboration diagrams (with several separate pools for the process participants instead of lanes).|
However, the usage of lanes might be meaningful for:
For these cases, also consider alternative methods to maintain and show roles:
As a visible part of the task name, e.g. in between squared brackets : "Review tweet [Boss]".
|During execution you can remove this part of the task name if you like by using simple mechanisms like shown in the Task Name Beautifier - so it does not clutter your tasklist.|
As a text annotation or a custom artifact
Note that roles are part of your executable BPMN process model as technical attributes anyway - even if hidden in the BPMN diagram. So they can be used e.g. during execution for assignment at runtime.
If you model on operational level (see BPMN Tutorial and book 'Real-Life BPMN' on details for modeling levels) use collaboration diagrams with several separate pools for the process participants instead of lanes: operational models using lanes make it very hard for the individual process participant to identify the details of his/her own process involvement.
Furthermore, model just one coherent process per pool (apart from event subprocesses, of course), even though BPMN in principle allows several processes per pool. This improves readability by constituting a clear visual border around every process and by providing a natural space for labeling that part of the end-to-end process in the pool’s header.
|1||The Team Assistance is responsible for initial "Invoice Collection" as well as "Invoice Clarification" - if applicable. Those two processes are modeled by using two separate pools for the team assistance, just as …|
|2||… the approver can see the "Invoice Approval" process in a separate pool and …|
|3||… the managing director can see the "Invoice Payment" process in a separate pool while the collaboration diagram as a whole shows the business analyst that the overall end-to-end process works.|
|Using collaboration diagrams with separate pools for the process participants allows to explicitly show interaction and communication between them by means of message flow and further improves readability by transparently showing the participants their own involvement in the end-to-end-process. As a consequence, they do not need to fully read and understand the end-to-end process in order to read, understand and agree to their own involvement by looking at their own pools.|
Consciously decide how you want to model systems the process participants are interacting with. Use data stores to show systems which primarily serve as a means to store and retrieve data. Use - depending on your needs collapsed or expanded - pools for systems which are carrying out crucial activities in the process going way beyond storing and retrieving data.
|1||A collapsed pool is used to represent a system which supports the process and/or carries out process tasks on its own. The pool could be expanded later to model the internal system details, maybe even with the goal to execute a technical process flow directly with a BPMN capable process engine.|
|2||A data store is used to represent a technical container meant to archive PDFs and store them for later retrieval.|
|3||Another data store is used to represent a container which could be a physical storage place for paper invoices to be paid at the moment but could become a representation for business objects in a database with the object state "to be paid" in the future.|
You may also want to use your own artifacts to visualize systems in case this better serves your modeling needs. A symbol depicting a desktop computer is offered by some modeling tools out of the box.
When choosing between those three options for modeling systems (data stores, collapsed pools, own artifacts) keep in mind that only pools represent processes and therefore have the capability to be expanded and modeled in all their internal details later on.
Avoid excessive use of data objects, but use them cautiously to show the most important data related aspects of your process.
|Experience shows that many data objects and especially many data associations quickly clutter your process model and that visual noise reduces readability - especially for less experienced readers.|
You might find three practices helpful to find your own "right" amount of data visualization:
|1||Cautiously use data objects and associations to show the most important data related aspects of your process. We could have modeled that all the tasks in the "Payments Creation" process either read, update or delete the "new payment", however we decided that we just want to point out that the process works on a new payment object.|
|2||Use data stores for coupling processes via data. We could have modeled a lot of other tasks in the process that either read or update the "payments", however, we decided to just point out the most important aspect for the process diagram, which is that the "Payments Creation" process of delivery service is loosely coupled with the "Payments Processing" via commonly shared data.|
|3||Use message symbols to add information regarding the message payload, but only if this adds something useful to the model. Here we decided that it’s helpful to know that this message does not only inform an adjustment possibility was checked, but that it also delivers all the necessary details of the adjustment.|
Leave the size of symbols as it is by default.
|Different sizes of e.g. tasks or events suggest that the bigger symbol is more important than the smaller one - a most of the time unwarranted assumption. Instead of writing long labels, use short and consistent labels in line with your naming conventions and move all additional information into BPMN annotations associated to your specific BPMN element.|
Furthermore, avoid excessive use of colors.
|Experience shows that colors are visually very strong instruments and psychologically very suggestive, but will typically suggest different things to different readers. Also a colorful model often looks less professional.|
However, there are valid exceptions. For example you could mark the happy path through a process with a visually weak coloring:
Another case for useful coloring might be to make a visual difference between human and technical flows within a bigger collaboration diagram by coloring the header bar on the left hand side of the pools.
No guarantee - The statements made in this publication are recommendations based on the practical experience of the authors. They are not part of Camunda’s official product documentation. Camunda cannot accept any responsibility for the accuracy or timeliness of the statements made. If examples of source code are shown, a total absence of errors in the provided source code cannot be guaranteed. Liability for any damage resulting from the application of the recommendations presented here, is excluded.
Copyright © Camunda Services GmbH - All rights reserved. The disclosure of the information presented here is only permitted with written consent of Camunda Services GmbH.