Building flexibility into BPMN models

BPMN modeling primarily targets structured processes, often with the goal to automate as many steps as possible, increase efficiency, and decrease process execution costs. But sometimes we need ways to build flexibility into such process models to deal with expected or unexpected operational problems or to allow for humans to intervene.

Understanding the required symbols

To build flexibility into BPMN process models, one must understand BPMN symbols and modeling techniques. After introducing the main symbols, we can demonstrate more concrete examples.

Use events as triggers

BPMN events allow us to react to all kinds of information. We can use them to trigger flexible activities. In particular, BPMN events catching messages, conditions, and timeouts are useful in that context.

Camunda 7 Only

Condition events are not yet supported in Camunda 8.

Boundary events to add activities on triggers

BPMN allows us to attach events to the boundary of activities to trigger some follow-up action. By modeling such an event as either interrupting or non-interrupting, we can decide to do the activities either instead of the activity we attach the event to, or in addition to it.

Subprocesses with boundary events

By attaching boundary events not just to individual activities, but also to subprocesses, we can flexibly define the area or scope for which we want to trigger some flexible activities.

1

While we are occupied with carrying out some area of activities, in a scope of our process...

2

...an event might occur, which causes us...

3

...to carry out this activity in addition to continuing with ordinary work.

Event subprocesses

Sometimes we need to build in flexible activities which are carried out at any point in time. In such cases, we can leverage BPMN's event-based subprocesses.

Escalation events

Sometimes we need highly flexible means to cancel scopes or trigger additional activities from within a scope. The BPMN escalation events can be particularly useful to implement such requirements.

1

As soon as we are finished with the first activity inside the scope...

2

...we inform the surrounding scope about that and trigger an additional, essential activity...

3

...but also continue with our second activity to complete the subprocess.

4

We can then already continue with the follow-up work regardless of whether that additional activity is already finished.

Terminate end events

To build flexibility into process models, it is also useful to remember that the termination end event just terminates the scope within which it is defined and therefore not always the whole process instance. With that technique, it becomes possible to cancel some activities inside a subprocess while completing it successfully and leaving it via the typical outgoing path.

1

As soon as one of our two activities achieves the result, we can cancel the other one...

2

...and successfully complete the subprocess and normally continue with our follow-up work.

Examples

Allow proactive order status communication

Assume that for an order to be validated, the customer must determine the delivery date before we can confirm the order. If the order is not acceptable—due to consistency issues or customer related issues—it is declined.

Some of our orders might be so important that we want to ensure we keep customers happy, even if not everything runs smoothly on our side.

1

Order managers can request proactive customer communication on demand. Assume they can communicate the reasons via a form, whereas the communication as such is carried out by the call center.

2

On a regular basis, we check based on some rules, whether the order is so important that we proactively communicate why the order is not yet confirmed. Again, the communication is carried out by the call center.

Allow for order cancellation any time

The customer might be allowed to request a cancellation until the order is confirmed. This request would have to be reviewed to determine whether we must accept the cancellation.

1

Whenever the customer requests a cancellation until the order is confirmed, we review that request and decide whether we have to accept the cancellation or not.

2

If we accept the cancellation, we must terminate the entire process. To do so, we need to use one trick: throw an error event that will end the current event subprocess, but not yet the order process.

3

This leads to another subprocess to be triggered, and this one is interrupting. Now, the process instance is really cancelled.

Allow for order details to change, but repeat order validation

Camunda 7 Only

Condition events are not yet supported in Camunda 8

If the customer changes the order details, the order must be validated again.