Introducing the Case Management Model and Notation standard: CMMN

We’ve been seeing increasing interest in using CMMN to model business solutions, and while many people have some familiarity with BPMN for business processes, there’s not the same awareness of this other OMG standard for describing case models.  What we’ll do in a series of blog posts is introduce the ideas and concepts behind CMMN and also how we’ve learned to use it in action.

If you’re coming to this from a BPMN background, or a procedural and process-oriented viewpoint, it’s worth adjusting your mind to think about things in CMMN in a declarative way.  CMMN describes what a situation looks like, its elements and phases; what actions and options are available to a person or system to take; and events that might trigger some action.  You can think of CMMN defining what you can do in different situations, with BPMN defining how you do it. BPMN tells you how to ride your bike from A-Z, while CMMN says here’s a bike when it’s needed.

There is an overlap in how you can describe a solution in BPMN and CMMN, with some saying you can do everything you need with BPMN (and occasionally, the other way around). Of course, you could do all of it in assembler programming language if you had the time, but that’s really not the point.  One of the main reasons for using models rather than code to describe a solution is that it’s easy to share an understanding of what’s being described, as well as easy to change quickly.  Naturally, you need to rely on a fast and scalable tool to run these models, but that’s precisely what Flowable can do.

A lot of introductory background so far, but coming to CMMN with the right perspective is important for you to gain its advantages.  So, let’s get into it and explain the main elements you work with.

Case model plan and use cases

Everything about a case is contained in a Case Plan Model, which is depicted visually as a large dossier.  A case plan can represent a wide range of business situations, with typical case management scenarios, such as loan applications, insurance claims, customer complaints, and patients in healthcare.  That doesn’t mean that conventional case management use cases are the only types of solutions that can be modeled by CMMN.  In this video we give an example of using CMMN to manage chatbots.

Case elements: Stages

Elements of a case are often grouped together in Stages, which might be used to represent the high-level phases of solving or completing a case (or situation), or for describing the life-cycle stages of some entity (onboarding, maintaining and offboarding a client or user; controlling a document for Records Management) or an event.  Visually, stages are shown as rectangles with cut-off corners (Receive claim in the figure below).

Case elements: Manual and automated tasks and milestones

Then you have Tasks of different flavors that represent some actual piece of work.  These might be Human Tasks, Decision Tasks, Process Tasks or Case Tasks among others.  These are drawn as rectangles with rounded corners.  Tasks can be placed inside the case plan or within a stage. An important feature of tasks is that they can be defined as starting manually or automatically, as well as be used multiple times.  The other element you’ll see used is a Milestone, displayed as a rectangle with semi-circular ends, which can be used to indicate when some key point in the case has been reached or met.

Case element: Event listeners and triggers

The final major elements are Event listeners, again with a variety of flavors, including Timer Event Listeners and User Event Listeners, represented as double-line circles.  As you might expect, these are used to trigger things when certain events occur.

Sentries and Links bring elements into play

These items together allow you to describe how bits of work might be structured together and potentially how they might be triggered.  There’s a couple of final bits of glue that tie things together to make all of it operational.  The first of these are Sentries (diamond shapes) that can be placed on items to determine when they are appropriate to start or be available (using an Entry Criterion), or when an item should be stopped or become unavailable (with an Exit Criterion).  Sentries provide much of the power of expressing how elements of a case can come into play.  The second bit of glue are Links that define dependencies between elements, not surprisingly represented by lines connecting the elements.

Is case modelling your thing?

Here’s a simple example of a CMMN model showing many of these elements.  There’s links to the CMMN and referenced BPMN models at the bottom of this article, so you can download it and run it with Flowable’s Community and Enterprise UIs. Can you work out what will happen when a case is started using this model? If not, you’ll have to wait until the next post when we’ll go into more detail about how a CMMN model executes.

Learn more about Case Management on our website.

You can load and execute the example app model in Flowable Open Source. Download Claims Case app for Open Source

For the Flowable Trial Download, there are more extensions to enable tweaking of the CMMN behavior in the enterprise version of Flowable, but the fundamentals of the CMMN engines are identical. Download Claims Case app for Enterprise Trial