BPMN-3.26.0: BPMN Element Restriction

The BPMN 2.0 standard offers a multitude of possibilities for process modeling. For new, but also for experienced readers and users, this can sometimes lead a lack of understanding and thus counteract the goal of BPMN: Intuitive process modeling of high quality without large entry barriers. Furthermore, organizations or teams often strive for a common modeling style. For example, certain BPMN elements should not be used because they may reduce the readability and comprehensibility of the model. Release 3.26.0 of the BPMN Modeler Enterprise Server introduces new functionality exactly for this purpose: Disabling single BPMN elements or whole groups of elements per Confluence space, that will no further be available for modeling.

Case Study: The Conditional Flow Element

An aspect of the BPMN standard that is commonly used is the possibility to describe conditions which determine the flow of the model. In the following figure we see such a condition. After an invoice has been created in the task colored in red, it must be sent to the recipient. The upper flow expresses that the customer is the recipient while the lower flow is executed if the insurance company is the recipient.

In the figure, the BPMN element "Conditional Flow" was used for modeling. Preferring flow elements over gateways seems like a good idea at first, as it keeps the model smaller and thus supposedly easier to understand. In fact, using Conditional Flow elements has a few pitfalls, which we will illustrate with three questions.

Can the customer as well as the insurance company receive the invoice?

Experience has shown that Conditional Flows are often read as being exclusive. In fact, however, it is equivalent to an OR split. So, if both conditions are met, both flow elements will be excercised. In our example, however, either the customer or the insurance company should receive the invoice. Since the conditions are not obviously mutually exclusive, it is therefore recommended to use an XOR gateway.

Can we differentiate between insurance partners?

In this case we would like to first decide whether the customer or the insurance company is the recipient and then make use of further conditions to differentiate between insurance partners. However, flow elements do not support cascading conditions. This is another reason why we should use a Gateway.

Can we join the flows afterwards?

Let us assume there are several recipients of the invoice, e.g. a customer and an insurance company. After two invoices have been sent, another activity follows. This activity will be executed several times and possibly asynchronously. One token will come from sending the invoice to the customer and another token from sending the invoice to the insurance as merging flow elements directly into an activity is equivalent to an XOR join. A synchronization and merging of the incoming tokens as with OR joins is not possible with flow elements.

After some consideration, the team thus decides to not use Conditional Flows in their Confluence space in the future and instead want to use Gateways. This decision can now be implemented directly in the BPMN Modeler Enterprise.

The Solution

In the space settings for the BPMN Modeler, which can be reached via the sidebar of the corresponding space, we added a new tab "BPMN Elements".

In this tab, individual BPMN elements as well as entire groups of elements can be switched off and on, so they are no longer available in the corresponding Confluence space. The space administrator of our team switches off the Conditional Flow and hits the Submit button.

Back in the BPMN Modeler, the effect can be seen immediately: The BPMN element "Conditional Flow" is no longer available.

The modeler of this diagram thus chooses to represent the process using Gateways. The new team convention was implemented easily and effectively.

Your Modeling Etiquette

Try it out for yourself and simply turn off unwanted BPMN elements when modeling directly in Confluence: With the BPMN Modeler Enterprise.

You are not using the BPMN Modeler yet? Feel free to contact us!