Flowable’s CMMN in action, part five – insurance claim, independent actions across a case

Once an insurance claim’s case is opened, CMMN allows you to follow pre-defined steps to automatically handle it. Of course, there are activities that aren’t necessarily linked to a specific stage of the case, such as, for example, updating a client´s contact details. These activities  exist outside the stages and may be needed at any given point, even multiple times. How are such independent elements and actions handled with Flowable? This blog post will provide the answers.

In the course of this CMMN series we’ve been showing one example of using CMMN to describe case management automation. In the previous post, we finally completed a case instance. Now, in this 5th and final post in this series, we’ll look at the two items that sit outside any of the stages in the example model:

• Human task: Update claimant contact details

• User event listeners: Abandon claim

Activating independent items

As you may realize by now, when a case instance is created, as well as the Receive claim stage getting activated, any other items at the top level of the case plan will also be evaluated. What does that mean for our two independent elements?  We have two items, Update claimant contact details, a human task and Abandon claim, a user event listener floating around, not linked to any other elements. As the task has no entry sentry to consider, it becomes immediately available.  However, because it’s manually activated it doesn’t actually get created and become active, even though the case plan is active. Similarly, the user event listener will only be available at this time, and will stay in a waiting-mode until the respective user event triggers its activation.

Defining and controlling triggering events

While we’re talking about event listeners, rather than user triggered events, there can also be events from external services, such as Kafka (see this blog). Using stages and event listeners inside them, you can define and control what events your case will be listening to.  Different events may be relevant at different points in the life-cycle of a case or problem. While some may always be relevant (modeled outside any stage in the case plan), even multiple times, others are optional or have rare usage.

Tip: You can read the eventing tutorial example from the trial download to get an idea of the different use cases. The CMMN model used in that example is shown below, where an event for a status change triggers different activities depending on which stage of the case is active at the time of the event:

Efficiently handling repeating elements

Back to the Update claimant contact details human task. This is a task that can potentially occur several times as the address or personal data of a customer might change more than once. To indicate that a task can be activated and run multiple times, you can see in the model alongside the manual activation icon a #. In case you are wondering how this works in practice: Each time the details need to be updated, you can manually trigger the creation of a new instance of the task to collect the changes. For any instance of a case, there can be multiple instances of the update details task, or even none. Not only human tasks, but any type of task, stage or milestone can be repeatedly activated.

Tip: As well as just saying an item can be repeated any number of times, you can have a repetition rule that determines if further repeats are possible. Each time a repeatable task completes, the repetition rule is evaluated and if true the task can be repeated (it becomes available again). Flowable has some extended capabilities to count the number of times an item is repeated, as well as other handy attributes.

Changing the perspective with CMMN

Well, that’s the end of our quick hands-on trip through CMMN. It is one of those things that if you’re used to BPMN, you need to adjust to a different way of thinking: describing what’s appropriate in different contexts, or reacting differently in different circumstances, plus most importantly, letting the user have control over what happens next.  We’ve covered some of the key introductory topics:

• some of the principal CMMN elements (plan items)

• the importance of understanding the activation lifecycle of CMMN plan items

• how sentries provide a powerful way to express relevance of solution components in different contexts

• and how you can express some things very naturally in CMMN that are not directly modelable in BPMN.

CMMN is not a replacement for BPMN, but an additional tool when you’re trying to express complex business problems.

In our experience, CMMN is a natural way to coordinate the high-level of a problem, to manage sets of business processes and information that relate together in some way. Often, there is an initiating process that creates a case, but then the dynamic resolution of a problem is nicely captured through CMMN.

There are plenty of complex things you can do with CMMN, and we’ve also added some extensions that we’ve found useful when dealing with real-world implementations. As mentioned at the beginning of this series of posts, Bruce Silver’s book, CMMN Method and Style is a great resource for learning more and adopting a best practice. Time to get on the case!

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.