Flowable’s CMMN in action, part three – using substages and milestones to investigate insurance claims

Many of the business processes handled by insurance companies are complex and require sophisticated management to be executed in an efficient, rapid, and reliable manner. Flowable addresses complexity using Case Management, allowing insurance companies to control every level of it in a model based approach. How to best model such solutions with CMMN in Flowable? In this blog post we explain the use of substages, event listeners, and milestones for contextual case execution.

We’ve been following through an example CMMN model as a means to introduce some of the ways CMMN can be used to describe case management automation.  In the previous post, we’d completed the first stage, Receive claim__, and were just about to dig into the second stage, Investigate claim.  What we’re going to do in this post is look at substages, event listeners and milestones, to control the execution of processes in more complex scenarios

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

Transitioning from one stage to the other

In our last post, we reached the step of closing the Receive claim stage through a user event listener connected to an exit sentry on the stage. This is how the transition to the next stage works in Flowable Work:

1. As a consequence, the associated exit event now triggers the entry sentry on the Investigate claim

2. This makes the Investigate claim stage active, in turn making its contents available and active as appropriate.

3. It will automatically start the process referenced by the process task Do claims adjustment, because it has no entry sentry.

In our definition of that process in the example app there are three user tasks in sequence, so the first of these will now be waiting for user input.

Clicking the task in the open list will display the task itself.

Starting the Investigate claim stage

In the Investigate claim stage, there’s one other element at the top level of the stage, but as it’s linked by a completed event, it will only become available when the process task has completed.  There are no forms associated with any of the tasks, so we can just Complete each one in turn.  Once that process completes, then the process task that referenced it from the case stage also completes.  If you’ve been following this series of posts, you’ll know that the element connected the process task by a complete event will now become active (there’s no other condition on the entry sentry).  But what is that element?

Using substages for extra context

It’s a substage – a stage within a stage.  There’s no limit to the nesting you can have, which allows you to control the scope of behavior in more complex scenarios.  The reason we’re using it here is because we want to give the user the option to select if they want to accept or reject the claim.  We could have done that within the process we called and passed out the decision as a case variable, but it’s not always possible if you have reusable process fragments called from a case.  Also, it allows us to explain some more CMMN by doing it this way!

Using event listeners for a seamless execution

We’re using user event listeners in this scenario because we don’t want to create an additional and unnecessary manual task to get the decision made.  We just want a couple of actions to be available to the user to signal the outcome.Note: with a real case management scenario, there may be a whole number of other activities that the user could possibly do within this stage before making the final accept or reject decision.

• One feature of user event listeners is that they cannot have entry sentries, but in our example, we only want the options for the user to appear once some state has been reached within the stage, not immediately.  Without entry sentries on the user event listeners, we need some other way to provide the scope for that context.  Substages can provide that scope.

We’ve reached the state where the process task has completed and the substage consequently has become active, so everything inside it is evaluated to see if they become active, enabled or available.  Suddenly, our two user event listeners become enabled and visible in the Flowable UI.

Using milestones for an automatic substage exit

When the user selects one of these options, the user event listener triggers and activates its linked milestone.  A milestone has no real behavior other than existing or not – in Flowable, if a milestone is made active, a variable is created for it.  With our example, as soon as a milestone occurs it triggers the substage to exit (see the exit sentries).  With the substage context gone, the user event listeners are no longer available to the user (the options are gone from the UI). With the process task and substage completed, there are no other elements in the Investigate claim stage that could become available, so the stage itself completes.  You won’t be surprised to learn the final stage, Handle claim, now becomes active.  We’ll see how the milestone can be used to trigger behavior in the next post.

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.