Flowable’s CMMN in action, part one – managing an insurance claim case

Managing an insurance claim requires both human intervention and system processing. Case Management seems to be just the right solution: it excels at complex and dynamic business processes by combining human and digital actions. How can you manage an insurance claim with CMMN in Flowable? And what do you need to consider when executing the different steps? Find the answers within this blog post.

In a previous post, we gave a lightning-fast introduction to the elements that make up a CMMN model, with an example to look at and even download to explore. Quick recap: Stages, Tasks, Milestones and Event Listeners. In this post, we´ll guide you through 5 important steps for managing a claims case with CMMN in Flowable.

We´ll look at a model in detail as well as at some of the must-dos when executing at scale. You can easily follow all the steps as we go along by using the enterprise trial version. Let´s dive in!

Step 1: Following the claim´s stages

To manage an insurance claim case successfully with CMMN in Flowable, we’ll need to follow the different stages of the process. When looking at a claim´s overall lifecycle, we see 3 stages that are sequential: receiving a claim, investigating it, and finally handling the claim. In Flowable this is modeled by a stage having an entry sentry (diamond shaped) connected to a completion event (a dashed line) of the prior stage. There’s also a couple of other elements floating around outside of any stage – you don’t need to have a stage, but they are generally useful for clustering related items. Stages can be nested too, bringing additional levels of scoping.

Step 2: Understanding the lifecycle of activation

A key concept in CMMN is the lifecycle of activation for elements.

With CMMN we’re always looking at what’s available and can be made active, either automatically or started manually by a user. CMMN is about making the right set of options available to a user, or automatically executed, at the right time and in the right circumstances. The main states in a case element’s lifecycle are shown in the figure below.

Tip: We’d recommend Bruce Silver’s book to go deep into this topic.

Step 3: Starting the case in CMMN

In order to manage your insurance claim, you will now be wondering how to start this lifecycle. Here is how it works:

• First, anything inside a container, such as a stage, only has a chance to become _available_if its container becomes active.

• Second, in order to start the lifecycle, the top container for a case, called a case plan (the big folder icon surrounding everything) needs to be active. When you now create an instance of a case, the first thing a CMMN engine does is check what items can be available. Anything directly in the case plan is immediately available. However, for any of them to become active, some conditions need to be met.

Our CMMN model in this example will help us understand these conditions in practice:

1. When an instance of the Claims case is created, the three top-level stages – receive, investigate, handle – all become available.

2. The stages investigate and handle have entry sentries that are conditional on events that haven’t happened yet, so they just remain available. However, the receive claim stage, on the other hand, has no entry sentry as it marks the start of the claim lifecycle. Consequently, this stage immediately becomes active.

3. The consequence: All the items inside that stage can become available (we’ll come back to the exceptions). In that stage there’s a human task called capture claim details also without an entry sentry. This one automatically gets activated too as soon as the stage gets activated.

4. The result: By creating an instance of this case model, we’ve immediately jumped to its first stage and kicked off a task!

Now, the exception: In addition to this automated process there is the possibility to execute manual actions. When an available item is marked as manually activated it is instantly made enabled, ready to become active at the click of a button by a user. This is why the human tasks add incident report from police and need 3rd party report don’t get started when the receive claim stage is activated, even though they have no entry sentry.  They sit, waiting enabled, until a user action starts one and a task is created.

Step 4: Tasks and event listeners

We´ll take a closer look at the Event Listeners now. User event listeners, such as Abandon claim and Details completed in the example, behave like manually activated tasks, as they wait for a user action to trigger them – the difference is that they’re treated as available rather than enabled. This is what Flowable Work looks like to the user after starting this case.

So far, we have created a case instance and got a first task. In our example, there’s also a task named Update claimant contact details in the top-level case plan and it’s manually activated. When we created the case, this task is also made enabled but will wait for a user action before being created. The Abandon claim user event listener is also in the top-level case plan, so it too is made available and will show as a user action.

In summary, after creating the case, we’ll have one user task created and four actions available to the user:

• Abandon claim

• Update claimant contact details

• Need 3rd party report

• Add incident report from police.

Please note: The Terminate action in the screen above is a global action for all cases and processes, not part of the individual case model.

Step 5: Connecting the dots

With the example app, we haven’t added any logic or forms to the tasks so it is easy to just step through. If we complete the Capture claim details task, its status moves from active to complete.

How does it work? Have a look at the case diagram. There, you´ll see a link from that user task to an entry sentry on a process task. The link represents an event that when it happens will trigger the entry sentry. It’s possible to have a condition expression on the entry sentry. In Flowable we show sentries with conditions by a yellow diamond.

In this example, there’s no condition, so the sequence follows like this:

1. The Capture claim details is completed by a user

2. The complete event triggers the Need additional information process, making it enabled

3. This process task is manually triggered, so it will wait for a user to actually start it

4. You’ll now find a new user action visible to you for this, as it wasn’t enabled before.

Moving on, the Details completed event listener is connected to an exit sentry (black diamond) on the stage. In the same way that an entry sentry can trigger and control things becoming active, an exit sentry can trigger something to exit, or finish.

So, what happens next? At this point, we could select the Details completed action and force the stage to exit, which in turn would trigger the event linked to the entry sentry on the Investigate claim stage and start it.

Curious about the various other features that allow you to manage your claims case? In the next post, we’ll look at the other tasks in the Receive claim case, which illustrate something that isn’t possible with plain BPMN! Stay tuned!

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.