With the release 3.23.0 of the BPMN Modeler Enterprise we extend the function for diagram validation of processes by the possibility to compile modeling rules directly in Confluence itself. Lead developer Belinda Felpel explains the challenges, the function of the new solution and, based on an example, why validation according to individual rules makes sense.
The BPMN 2.0 notation is designed so that anyone can start process modeling intuitively and without major entry hurdles. The BPMN Modeler Enterprise for Confluence also pursues the goal of making the means and tooling available to everyone. This is the only way to develop process models that reflect reality as best as possible and in which the knowledge of all those involved flows together.
Of course, it cannot be avoided that inexperienced modelers in particular make a few mistakes at the beginning and fall into typical traps.
Identify typical stumbling blocks
In order to support our users in creating not only syntactically correct, but also semantically meaningful and easily understandable process diagrams in an easy and efficient way, there is the Diagram Validation Feature in the BPMN Modeler Enterprise.
We have already discussed this in detail in an earlier blog post (Improve the quality of your process models with diagram validation).
Here is an overview of the validation rules once more:
- Elements always require a label
- A (sub-)process requires at least one start and one end event
- A (sub-)process might only have one unspecified start event
- In an event-based sub-process, the start event must be specified
- All elements must be connected
- Multiple incoming sequence flows to an activity must be merged in a gateway before
- Sequence flows might not be split implicitly in an activity, but rather be split by a gateway afterwards
- There cannot exist duplicate sequence flows (equal start and end)
- No redundant gateways (only one source and one target)
- Gateways may not simultaneously merge and split sequence flows
An example of necessity
Take an inexperienced modeler, a syntactically correct BPMN model and an automation engine.
You could end up with something like this:
At first glance this looks intuitive. But if you take a closer look with a trained eye, you will see the core of the problem. If this process model is fed into the automation, the following happens:
- A repair is requested
- Cost is assessed
- At the same time, the invoice is created and the repair is made
- After both are completed, the invoice is sent to the customer. But twice!
- The customer is confused and angrily calls the workshop.
A simulation of the process flow clarifies what was probably not intended here:
- The implicit fork leads to two parallel process flows.
- The implicit union of the flows does not have the presumably expected result of merging - there remain two tokens.
- Therefore the invoice is sent twice to the customer.
- And the subsequent process is started twice.
This inaccurate modeling would have been noticed in the diagram validation, because it is required as best practice not to use implicit joins, but always to make them explicit using gateways:
Put together your own set of rules
The above example illustrates how unexpected behavior can occur despite the process model being valid BPMN 2.0 notation. For this reason, it is always advisable to agree on best practices and to make them clear - for example visually by using diagram validation during modeling.
Since every company and possibly every business department has individual requirements and more or less strict rules, the new release 3.23.0 of the BPMN Modeler Enterprise now offers the option of composing your own set of rules. Rules can be managed at Confluence space level, so that the diagram validation can be adapted to your own needs at any time.
The rules mentioned above remain the standard set and they are validated by default, But as a Confluence space administrator you have the option of setting the error level of the individual findings. You can choose between 'Error', 'Warning' or alternatively simply switch off the validation of a rule altogether.
To do this, as the space administrator, go to the space settings, select the "Apps" tab and find all validation rules with individually adjustable error levels for the BPMN Modeler.
This way, one can decide that in the above diagram the implicit union has to be reworked, but company-wide it is perhaps not unusual that a process flow forks even without a gateway.
Now it's your turn!
Do you also want to improve your process models and choose your own rules? Simply update your already installed app or try it out for free with an evaluation license in the Atlassian Marketplace.
Back to blog overview