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.
Condition events are not yet supported in Camunda Cloud.
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.
1While 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​
Escalation events are not yet supported in Camunda Cloud.
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.
1As 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.
4We can then already continue with the follow-up work regardless of whether that additional activity is already finished.
Termination events​
Termination events are not yet supported in Camunda Cloud and only available in Camunda Platform 7.
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.
1As 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.
1Order 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.
2On 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.
1Whenever 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.
2If 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.
3This 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 Cloud
If the customer changes the order details, the order must be validated again.