Using CMMN to Go Beyond Case Management

CMMN was mainly designed with case management in mind to handle dynamic, human-driven processes, where the execution is not always a straight line, but might involve human decision to drive the process forward.

With the "stage" element, CMMN allows to divide the main end-to-end business case into several steps, also known as phases. This approach not only makes things clearer visually but also helps manage complexity by setting rules for when to enter, exit, or repeat a stage if needed.

While BPMN focuses on step-by-step execution, CMMN handles processes based on events or changes, where certain conditions trigger actions. This allows CMMN to manage and monitor the overall process and activate necessary tasks accordingly.

In a typical CMMN model, stages include conditions for what must happen and what is optional. The detailed execution of tasks within a stage is often handled by BPMN. This setup allows CMMN to break down complex processes into smaller tasks, monitor them, and ensure everything stays within defined rules for compliance.

Credit card origination process example

In this example, we look at a simplified credit card origination process, built with CMMN at the high level and BPMN at the detail level.

We divided the overall process into five stages, each handling a specific part, with clear transitions between them based on conditions if needed.

In the "referral" stage, there's a manually activated, repeatable "ad-hoc task" for adding any unforeseen work. Since this task is included within the stage and not globally, it means additional tasks can only be added during the manual review of the application. This way, CMMN gives an overview of what must be done in each stage and what can be added either through set conditions or manual decisions.

The "review application" task within the "referral" stage was defined using BPMN:

This simple example illustrates, how CMMN and BPMN can be leveraged as a combination to model and end-to-end case with a great overview of the several parts of the overall process.

Using CMMN to orchestrate BPMN

In the previous example, CMMN was used to model a credit card application process, which includes both required and optional human tasks, like those in the "referral" stage.

This is a common case management scenario. However, we also saw that CMMN can orchestrate automated processes modeled in BPMN. Even in a fully automated process without human involvement, CMMN is helpful for breaking down a complex process into smaller parts, making it easier to manage by using CMMN’s rules and conditions.

With elements like the entry / exit sentries and conditions as well as repetition and rules, this can add a substantial amount of complexity at the CMMN level and taking it away from the underlying BPMN models becoming more manageable. This is also a great way to build a complex model in regard to maintainability and changes in the future as multiple simple and smaller process models can be maintained way easier.

This can also be done using the call activity (sub-process) in BPMN only, you say? Sure, but then you still lack all the condition / state / event logic you can easily model in CMMN. But we will see a bit more in the next chapter, when we add events into the picture.

Using CMMN to orchestrate events

In earlier chapters, we saw how CMMN can simplify BPMN by adding an easy-to-manage orchestration layer. When we introduce events, CMMN becomes even more useful, as it handles parallel events and tasks happening at the same time very effectively.

The case in CMMN creates a framework where processes can run, even in parallel, and events can occur during execution. CMMN can also manage the state separately from the processes, allowing parallel tasks to run faster and then merge the results back into the case when needed.

Let's look at an example to explore how CMMN handles events in a case:

The case has three stages, where stage B follows stage A and C follows B, very simple. But we have some event listeners (the double-rounded element):

• Event A, B and C can occur at any time, so we put them outside any stage (global event listeners for this particular case).

• Whenever event A is happening, it is handled in the followed process task, taking care of the event and executing whatever is necessary to handle it, taking the case context into account of course. It has no effect on the running stages and the overall state of the case.

• Event B on the other hand immediately starts stage B and even terminates stage A, if still running as whatever that event represents, if happening, stage A is no longer needed, kind of obsolete, but we need stage B immediately. If we would want to only catch that particular event, while stage A is in execution, we would put it into stage A and not outside where it can be caught regardless of the case state. If placed outside (globally) and with the repetition property of stage B (only executed once as we didn't at repetition), it will be ignored, if stage B is already running or has even completed. This gives you very great power to exactly define when to listen to an event and how to handle it and even what impact it might have on the running state of the overall case.

• Event E simply starts stage C if not yet started, but other that that has no impact on the other stages.

• Event D is interesting as it is only "listening" inside stage B, meaning, it only makes sense to process, while being in stage B. But it will completely terminate the case and end it, regardless of any other information. Assume stage B would be something like a review stage and the event representing something like a cancel request. As soon as me moved passed the review stage and entered the execution stage, it would be too late to cancel, so we only want to process it beforehand.

• As you see with the hash symbol, events can either be single-execution or repetition. If event D happens for example, we terminate the case, so there is no need to catch it multiple times. The same with event B and C, as they activate / end stages which don't repeat, we only can catch and execute those once. But Event A and E can occur multiple times and its connected handling process, so we declare them to be repetitive. Repetition is another great feature in CMMN as you can exactly define how everything behaves at runtime.

Of course, there is way more to event handling like correlation definition and calculation (where to send an event or which case / process is currently listening to what kind and type of event, etc) or event conditions, repetition and a very interesting feature: event deferring.

Assume you have an event listener within a claims handling case of an insurance company, triggered upon arrival of an invoice for that case. But maybe the case is not yet in a state where it can handle the invoice, so you want to "remember" it and process once the case becomes available to handle such events. That's where event deferring comes into play, allowing you to "park" events until the case becomes ready to process them.

As you can imagine, CMMN can play a very nice role in handling events, processing them and handling the state, conditions and parallel execution as well as data isolation extremely well.

Using CMMN as a complex state model

When you look at a typical CMMN model, you immediately get the "stage" element where you can define the different "phases" or "steps" or whatever you want to name them. If you would map them directly to a business state of an object (e.g. a customer, an invoice or even a very technical like a machine state), you get a nice state model. So we even let you model this directly as part of a stage in CMMN, connecting it one-to-one with any external business object.

As CMMN has way more than stages obviously, you can define everything you need when transitioning from one stage (state of the object) to another, which ones even would be possible, what needs to be done in between, conditions to enter a certain stage / state and even external events triggering those transitions as we saw in the previous example.

As a simplified example, we can have a look at an invoice CMMN model, where the stage and even sub-stage is directly mapped to the state of the invoice itself:

The CMMN model obviously does not contain any execution semantics like process tasks, conditions and the like as it only focusses on the stages mapped directly to the state of the invoice. The only thing additionally added are some events like when the payment is received within the "pending" stage, it will move to the "settled" stage, regardless the sub-stage and time events are used to drive from "issued" to "reminded" and eventually to "escalated", if there is no payment in time.

Case context and data scoping

In all the examples mentioned before, you can benefit from a very important concept: Data scoping and case context. Especially when handling events and executions in parallel, data scoping is a very essential concept to not overwrite data concurrently through various parallel executions happening at the same time. Flowable provides data scoping, so each execution can have and handle its own data scope which is eventually merged into the broader overall case context, if needed.