Creating readable process models

We create visual process models to better understand, discuss, and remember processes. Hence, it is crucial that models are easy to read and understand. The single most important thing is to use well-chosen labels.

Essential practices

Labeling BPMN elements

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 only as good as its labels.

1

Start event labels informs the reader of how the process is triggered.

2

An activity - labeled as "activity" - informs the reader of the piece of work to be carried out.

3

Gateway labels clarifies based on which condition(s) and along which sequence flow the process proceeds.

4

Labeled boundary events clearly express in which cases a process execustion might follow an exceptional path.

5

Labeled end events characterize end results of the process from a business perspective.

Recommended practices

Modeling symmetrically

Try to model symmetrically. Identify related splitting and joining gateways 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 gateway pairs as symmetrically as possible, the readability of process model is improved. The reader can easily recognize logical parts of the diagram and quickly jump to those parts the reader is momentarily interested in.

Modeling from left to right

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 occur, one can improve the readability of process models significantly:

Modeling from left to right supports the reading direction (for western audience) and supports the human field of vision - which prefers wide screens.

Creating readable sequence flows

Consciously decide whether overlapping sequence flows make your model more or less readable. On one hand, avoid overlapping sequence flows where the reader will not be able to follow the flow directions anymore. Use overlapping sequence flows where it is less confusing for the reader to observe just one line representing several sequence flows leading to the same target.

Avoid sequence flows violating the reading direction, meaning no outgoing flows on the left or incoming flows on the right of a symbol.

1

The author could have made the five (!) sequence flows leading into the end event visible by separating them. However, by consciously choosing to partly overlap those flows, this model becomes less cluttered, therefore less confusing and easier to read.

2

The author could have attached the sequence flow, leaving this task on its left. However, this would have decreased readability, because the flow connection violates the reading direction. The same applies to incoming flows on the right 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. Oftentimes, removing lanes can improve readability! Rearrange the order of pools in a collaboration diagram to avoid message flows crossing 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 very long (multi page) sequence flows, especially when flowing against the reading direction. The reader will lose any sense of what such lines actually mean. Instead, use link events to connect points which are not on the same page or screen anymore.

1

You observe 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 excessive use of link events. The example above serves to show the possible usage, but at the same time, it is too small to satisfy the usage of link events in real-world sceanrio!

Modeling explicitly

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 consider the central goal of increased readability and understandability of the model when deciding whether to model explicitly or implicitly. When in doubt, it's best to favor an explicit style.

Using gateways instead of conditional flows

Model splitting the process flow by always using gateway symbols like instead of conditional flows .

1

For example, you could've left out this inclusive gateway by drawing two outgoing sequence flows directly out of the preceding task Choose menu and attaching conditions to those sequence flows (becoming 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.

Modeling start and end events

Model the trigger and the end status of processes by always explicitly showing the start and end event symbols.

caution

Process models without start and end event cannot be executed on the Camunda workflow engine

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'.

Separating splitting and joining gateways

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 two incoming sequence flows to the task "Review tweet" could be merged with an XOR gateway, following explicit modeling. We argue that a merging XOR gateway directly behind the start event decreases the readability. A merging XOR gateway is a passive element and the reader expects the process to continue with an active element after the start event.

Using XOR gateway markers

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.

Splitting sequence flows with parallel gateways

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 likely need to understand the semantics of a parallel join combined with the preference for modeling symmetrically leads us to prefer explicit parallel gateways, too.

Joining sequence flows with XOR gateways

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 couldn't 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 most 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!

Avoiding lanes

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:

• Strategic level models (refer to BPMN Tutorial and Real-Life BPMN on details for modeling levels) - especially when they have a focus on responsibilities and their borders.

• Technical/executable models with a focus on human work-flow and its ongoing "ping pong" between several participants.

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]".

Camunda 7 Only

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

Roles are part of your executable BPMN process model as technical attributes anyway - even if hidden in the BPMN diagram. For example, they can be used during execution for assignment at runtime.

Helpful practices

Emphasizing the happy path

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 often as possible.

The five BPMN symbols belonging to the happy path are put on a straight sequence flow in the center of the diagram.

Avoid modeling retry behavior

A common idea is to model retry behavior into your process models. This should be avoided in general. The following process model shows a typical example of this anti pattern:

All operations use cases put into the model can be handled via Camunda tooling, e.g. by retrying or Camunda Operate.

Using collaboration diagrams

If you model on an operational level (refer to BPMN Tutorial and Real-Life BPMN on details for modeling levels) use collaboration diagrams with several separate pools for the process participants instead of lanes as operational models using lanes make it very hard for the individual process participant to identify the details of their 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 observe the "Invoice Approval" process in a separate pool and...

3

...the managing director can observe 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.

Showing interaction with systems

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.

When choosing between those two options for modeling systems (data stores, collapsed pools) 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.

Avoiding excessive usage of data objects

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

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.

Avoiding changes to symbol size and color

Leave the size of symbols as it is by default. For example, different sizes of tasks or events suggest that the bigger symbol is more important than the smaller one - an often 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. Additionally, 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 side of the pools.