previous
20/05/2019

Introduction to CMMN – Part 2: Task Types

Introduction

A few weeks ago we modeled the process to order a cocktail (read all about it in our previous blog). Through this example we wanted to introduce the basics of CMMN in an understandable context.

We’ve already discussed tasks, milestones, and stages and their roles in the Case Plan Model. 

The model we use as our example can be seen below.

Click this link to download/see a bigger version of the poster.

Overview of all ‘Task Types’

The process to handle a cocktail order consists of different tasks. Every taks has its own task type, indicated with an icon in the top richt corner of a task-element.

There are 5 possible types of tasks:

  1. Human blocking: a task executed by a knowledge/case worker. This task can only be completed once all the work related to it has been done.
  2. Human non-blocking: a task executed by a knowledge/case worker. This task is ‘completed’ as soon as the work has been initiated. This allows the case worker to also start other tasks in parallel. The non-blocking element ensures that other tasks don’t have to wait for completion of all the work related to this task.
  3. Process: allows invoking a BPMN-process
  4. Decision: allows invoking a DMN-process/decision tree
  5. Case: allows invoking another CMMN-process

The next paragraphs will explain each task type based on our ‘Cocktail Mixing Model & Notation’.

‘Human blocking’ tasks

You’ll see that most of the tasks in the process to order a cocktail are executed by humans (logically). Additionally, most human tasks in our example are ‘blocking’, such as ‘Take order‘.

This means the milestone ordered‘ can only be reached once the work associated with ‘Take order‘ has been completed and the task closed.

Another example is the task ‘Choose appropriate glass‘, the ‘blocking’ makes sure other tasks such as ‘Add ice‘ have to wait until all the work related to ‘Choose appropriate glass‘ has been completed (this could be: select glass, rinse glass, dry glass, etc.).

 

‘Human non-blocking’ Tasks

These tasks are very similar to Human blocking tasks, but they don’t stop other tasks from being initiated.

The task ‘Shake‘ is a good example. The mixologist could be shaking the cocktail in one hand while initiating work for another task such as grabbing another bottle of liquor to  ‘Add liquor‘.

 

‘Process’ Tasks

These tasks invoke a BPMN process or a BPM-driven system. The outcome of this BPM-process can be used as information to complete the task in the case file and to continue the handling of the case. Allow us to explain this using an example:

As you can see the task ‘Process payment‘ activates the payment processing system, which exists outside of and works independently from the case management system. Once the payment has been processed the payment processing system can send back information, allowing the case worker to close this task.

 

‘Decision’ Tasks 

Such task types are used to invoke DMN-driven systems. The outcome of these systems is a decision which will impact the next steps of the case handling.

As you can see in our model, ‘Calculate price‘ invokes a Decision-tree to come to an answer of what the price should be. In the DMN-driven system there could be several rules to determine the price and applicable discounts (e.g. a loyalty discount). The end result is to come to a decision of what the cost of the bill is for the customer. This information is then used to finish this task and move on to the next one.

 

‘Case’ Tasks 

Just like process- and decision-tasks, a case task will activate another process. However, this is another case handling workflow that also lives within the adaptive case management solution.

Review menu card‘ offers a good example. In our model reviewing the menu card is a ‘case’ where the case worker (the mixologist) has to complete several tasks. The tasks in the case of reviewing a menu card have nothing to do with the tasks related to completing the cocktail order. Hence the people modeling these processes have separated them into two case plan models.

These 5 task type indicators make it easier to interpret a case plan model. In our next blogpost we’ll take a look at the difference between discretionary and ‘normal’ tasks/stages, and we’ll also discuss the two types of event listeners.

Don’t hesitate to email us at info@groundlion.com should you wish to discuss how we can help you.

Written by: Dries Lamont, Marketing Manager, with input from Gert Becqué, Product Manager

Share this post
next