Flowable’s CMMN in action, part two – insurance claim, dealing with unpredictable events

Dealing with unpredictable situations can be a challenge, regardless of the context in which we operate. This is why when it comes to business processes, it is especially important that business reacts effectively to unpredictable events to ensure a seamless customer journey and maintain customer satisfaction. While BPMN needs various work-arounds to achieve this, CMMN is just the right solution: it provides both the required flexibility and customization capability for each case. Find out in this blogpost how to deal with unpredictable events using CMMN in Flowable.

In the previous post, we started to manage an insurance claim. Quick recap: We´ve been following through an example insurance claim case with CMMN in Flowable, to introduce some of the ways to use CMMN to describe case management automation. We started and then completed the first task, Capture claim details, within the first stage, Receive claim. Doing that had just enabled the process task, Need additional information, for the user to start if needed.

Our insurance claim process would typically follow a standard path, triggered by dependencies between case elements. But what happens when an unexpected event occurs? What we’re going to do in this post is explore how dependencies can be modeled to serve both routine and dynamic events.

Note: You can easily follow all the steps as we go along using the enterprise trial version.

Understanding the dependencies within the stage

Before we continue with our insurance claim example, it’s useful to point out that the manually activated process task, Need additional information, can be run multiple times, as indicated by the repetition marker #. Any time more information about the claim is needed, the process can be run again as a new process instance linked to the case. Looking at the other three manually activated human tasks in the Receive claim stage, we can see that there are dependencies linking two of them to the Add incident report from police task. Let’s take a closer look at these:

Following the execution path of dependencies

After highlighting these dependencies, we need to understand what this means for the execution of our claims case. Let´s assume we went through the previous steps and now click the Add incident report from police action: as expected, several things will happen, as you can see in the screen below.

Handling unexpected events with dependent elements

So, what happens after these automatically triggered actions? Maybe you’ve already realized it, but by starting the police report task it triggered the exit sentry on the 3rd party task. The result: it is no longer an option for the user to start. In fact, if the user had already manually started the 3rd party task, starting the police report task would have automatically terminated it. The same applies if it had been a process task that had started running a process instance: the exit sentry would have terminated the running process. Not only actions have been executed, but also tasks have been successfully closed.

Our claim case can be extended to show a really clear and powerful use-case to represent unexpected or unpredictable events in CMMN, which BPMN can’t handle easily.  How so? Imagine a situation where a customer services process has been started to refund a failed delivery of a purchase from an online store.  This process is going through the necessary checks with the delivery company followed by approval steps to get the customer refunded, when suddenly the customer says the original package has just arrived. What happens now?

At this point we are dealing with an unexpected event. The process cannot be completed as the refund is not necessary anymore. How can CMMN handle this case?

The flexibility of CMMN

With CMMN, we only need to provide a user event listener or manually activated task that connects to the delivery process task with an exit sentry.  That’s it – clearly visible in the CMMN diagram and achieved in a couple of clicks with the model. Many business activities are complex and non-recurring, like the claims case we just saw. Case management is designed for dynamic situations where many different decisions or options are possible.  Having the flexibility to adapt and adjust to unexpected situations is all part of CMMN. Have fun trying to do that with BPMN 😉.

Completing the Receive claim stage

Let’s close off this post by completing the stage. Because there are so many user-driven manual options in this stage, we’re using a user event listener, Details completed, connected to an exit sentry on the stage. This allows the user to say they’re all done here. Execute the user event and the stage will exit.

The Receive claim stage has an exit event as the trigger for the entry sentry on the Investigate claim stage, which means that stage will become activated as soon as the user selects Details completed.

Note: With Flowable, you can actually select the event type for the exit sentry, so you could use a standard complete event linked to the next stage if you wanted.  We’ve added a number of extensions to how CMMN can execute for convenience or that have arisen from customers, as is always the way with standards when used for real.

Would you like to learn more about automated executions that come from CMMN’s flexible dependencies? In the next post, we’ll see how nested stages can be used to handle situations where we want to group dependencies.  We’ll also introduce the use of milestones to help test earlier outcomes.

You can load the example app model into the Flowable Trial Download.

Learn more about the advantages of CMMN in complex and dynamic business processes in our CMMN eBook.