Avoid Typical Errors in Process Models Through Design Patterns

by Christian Mächler

15. April 2024 6 minutes

We use our most frequently encountered problem in process automation to illustrate the benefits of design patterns.

Design Patterns and Anti Patterns

Design patterns are blueprints that show how a particular problem can be solved reliably. They can be combined as desired and inserted into models. Design patterns also sensitize you to possible problems and can help to break down complex processes into simple building blocks. While there is a wealth of established design patterns in other areas (e.g. object-oriented programming), this is still virtually uncharted territory in process modeling.

The opposite of the design pattern is the anti pattern, which describes things that should be avoided. For example, merging parallel gateways with exclusive ones (tokens would not be consumed).

Overview of the Practical Examples

  1. Update of a Timer: the most frequently encountered error in the automation of a process.
  2. Updatable Timer Pattern: a design pattern to solve the problem.
  3. Update of a Boundary Timer: generalizes the previous problem.
  4. Complete 1 of N Pattern: a seemingly independent design pattern that should be used with caution.
  5. Updatable Boundary Timer Pattern: combines the "updatable timer pattern" and the "complete 1 of N pattern" into a new design pattern and thus solves the generalized problem.
Check out the BPMN files on GitHub

Update of a Timer

The following model is an abstracted version of the problem from practice. The essential part is the timer, which waits for a date stored in a variable releaseDate. The principle remains the same, even if the variable for the timer is set differently depending on the workflow engine. The process is executable and works, but why are variable updates ignored by the timer?


When a timer is reached, it is evaluated immediately and the time for the continuation of the process is saved. If this were already over, the process would continue immediately. After the calculation of the continuation time, variable updates no longer have any influence on the timer. The model also does not show that the release date could change. The following design pattern solves the problem and visualizes the possibility of timer updates. Due to this visualization in the model, it is advantageous to consider this at an early stage and not only during automation.

Updatable Timer Pattern

The design patterns in this article are deliberately kept general and reduced to the essentials. They are not solutions to the problems presented, but building blocks for them. To solve the above problem, the timer must be replaced by the following design pattern. Start and end events are not part of the pattern, but show where the flow comes in and goes out again.

Updatable Timer

This design pattern uses the properties of the event-based gateway, which continues the flow in the direction of the event that arrives at first. This means that only events may immediately follow the event-based gateway. Timers are evaluated when the gateway is reached, as if the timer itself had been reached. Message events allow variable updates in certain process instances at exactly this point in the process and not otherwise. If the process is now waiting at the event-based gateway, a message can be used to update the date variable. We then lead the flow back to the event-based gateway, so the timer is re-evaluated (new timer instance, old one discarded when the flow continued in the other direction) and messages can still be sent. As soon as the timer is triggered, the flow continues in this direction and no more such messages can be sent to the process instance.

Updatable Timer2

A condensed version of the pattern. It does not comply with the design guidelines, even though it appears to be clearer.

Update of a Boundary Timer

What about boundary timers, how can we update them? It is not possible to use an event-based gateway as a boundary event. We need a new design pattern to solve this problem, one with two possible outputs.


Complete 1 of N Pattern

This design pattern allows the creation of various tasks, only one of which can be completed. It works similarly to an event-based gateway with tasks instead of events. There should be never more than one user task. Otherwise, it can happen that users work on different tasks at the same time, but only one can complete his/her task, meaning that the work of the others was in vain. Viewed in isolation, the pattern does not seem very useful, but it can still prove to be a useful building block.

Complete1of N

First, we create a sub-process so that we can simply consume tokens without affecting the rest of the process. The parallel gateway generates a token for each of its outputs, which then waits at the respective task. After completing a task, all tokens in the sub-process must be destroyed immediately afterwards (same transaction), otherwise it would be possible to complete more than one task. This is done either with a terminate end event, after which it continues normally (happy path) or with interrupting boundary events, which catch the errors or escalations thrown by the end event in the sub-process. With different escalations or errors, separate outputs can be defined in order to react differently depending on which task has been completed.

Updatable Boundary Timer Pattern

With the previously developed design pattern, it is possible to separate the boundary timer from the task and still retain the functionality: It is possible to either complete the task or trigger the timer, but not both. Because the timer is no longer a boundary timer, we can easily replace it with the updatable timer pattern and thus obtain the updatable boundary timer pattern.

Updatable Boundary Timer

Closing Words

With these practical examples, we have hopefully been able to demonstrate the advantages of design patterns and awakened your interest.
We would be delighted if a library of established design patterns were to gradually emerge in the BPMN area as well.

Related topics

3 Abstraktionsebenen der Prozessdokumentation

Three abstraction levels of process documentation

22. April 2024

More success through documented processes. Our blog post introduces the three abstraction levels of process documentation: strategic, operational and technical. Find out how they differ in depth and detail and how Business Process Model and Notation (BPMN) optimizes your process modelling.

Wie Prozessmanagement die Servicequalitat in Unternehmen verbessert

How process management improves service quality in companies

18. March 2024

The key to success in today's business world is well-structured process management in order to increase service quality and stand out from the competition. Find out how efficient processes make the difference.


The role of process digitization in the business environment

12. December 2023

Process digitization focuses on the optimization and automation of manual processes through the use of technology. In this blog post, we would like to take a closer look at various facets and the benefits of process digitization.