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.
Condition events are not yet supported in Camunda Platform 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.
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 are not yet supported in Camunda Platform 8.
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.
To build flexibility into process models, it is also useful to remember that the termination 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 "normal" 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.
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
Condition events are not yet supported in Camunda Platform 8
If the customer changes the order details, the order must be validated again.