Get started with BPMN, CMMN, and DMN in Visio *

Use the Trisotech Free Visio templates to create visual representations of your operations using the BPMN, CMMN, and DMN notations.

Download Free Templates
Templates

To get you started, these templates include stencils containing all shapes and markers of these three standard notations. You can then utilize all the familiar features of Visio to apply variants and styles to customize your drawings. Simply use these templates to get you started on your journey to become acquainted with the triple crown of process improvement standards.

* Requires that you have a version of Visio.

The triple crown of process improvement standards

The Business Process Model and Notation (BPMN) , the Case Management Model and Notation (CMMN) and the Decision Model Notation (DMN) are powerful and expressive standards published by the Object Management Group (OMG) . This triple crown of process improvement standards offers universally recognized graphical notations in support of organizations seeking efficiency and effectiveness of their operations.

Triple Crown
Digital Enterprise Suite icon

Go beyond just a Visio drawing

Creating Visio drawings describing your operations is a great first step toward Digital Transformation. To fully leverage your existing Visio drawings and take them to the next level, you can import them in the Trisotech’s Digital Enterprise Suite to instantly obtain these benefits:

Start a Free Trial
Trisotech

the
Altruist

View all

Slider
Sandy Kemsley's Blog - Understanding the Why, not just the How, of the BPMN-CMMN-DMN Triple Crown
Sandy Kemsley
Blog

Understanding the “Why”, not just the “How”, of the BPMN-CMMN-DMN Triple Crown

By Sandy Kemsley

Read Time: 8 Minutes

Last week was the annual DecisionCAMP conference, where mostly-technical decision management (DM) aficionados gather to talk about the technology, standards and application of DM.

I attended in person last year, but this year was all virtual, and I helped to organize the conference platform using Zoom for live presentations, YouTube for rebroadcast (you can see replays of the presentations there), and Slack for discussion. Although not a replacement for an in-person event, we did manage to capture some of the camaraderie and interactive conversations that would have happened if we had all been in the same room. We even had an after-conference Zoom cocktail hour on the last day!

The great thing about DecisionCAMP is that it’s really a grass roots labour of love by the DM Community site, rather than a for-profit or vendor-sponsored conference. Vendor presenters are requested not to plug their products, so the presentations are a combination of university research, updates and usage of the DMN (Decision Model and Notation) standard, and case studies of practical applications. For a process-centric practitioner/analyst like me, there are always interesting presentations exploring the overlap between decisions and processes. The most noticeable example of this was in a presentation on the “triple crown” of business modeling standards, namely, the Business Process Model and Notation (BPMN), Case Management Model and Notation (CMMN) and DMN.

In my post on designing for agility, I mentioned that agility often depends on the design decisions such as the split between process and decision logic – what do you model in as a decision, and what do you model as a process – and went into some detail on when to consider splitting out decision logic from a process. Unsurprisingly, many DM practitioners don’t think first about processes, but suggest that you first focus on determining and modeling your business decisions, then build processes to gather the information and execute the steps required to make those decisions. Within those decisions, however, they often use rule flows, which are really processes that link together individual rules/decisions into larger decisions; this starts to muddy the waters in terms of designing decisions and processes, and may spread your processes over two different model types. To this we add case management (CM), which also provides some process and decision modeling, but may also link to DM and BPM models. Three model types based on three standards: this is the triple crown of process improvement standards.

Triple Crown
Download Infographic

The standards show how to combine the models: use a decision task in a BPMN or CMMN model to call a DMN model; use a case task in a BPMN model to call a CMMN model; or use a process task in a CMMN model to call a BPMN model. What the standards don’t show is why to combine the models, that is, what parts of the business to model using which standard. Technical proponents of the standards talk about applying the three standards to the “core management practices”, as if businesses were aligned along managing processes, cases and decisions, rather than their actual business capabilities and functionality. From a business operations standpoint, processes, cases and decisions are “implementation details”, not management practices.

There are some general guidelines for combining the standards, such as using CMMN for less structured knowledge work and BPMN for more structured processes, and DMN with either of those for repeatable business decisions. If you have ad hoc processes and decisions, that’s most likely to be modeled completely in CMMN, while repeatable processes with repeatable decisions would combine BPMN and DMN. However, many business scenarios aren’t that clear-cut, and contain a combination of ad hoc and repeatable processes, as well as ad hoc and repeatable decisions.

This presents two challenges.

First, business analysts who are tasked with documenting and analyzing business operations not only need to understand how the business works, but also need to decide how to map different parts of the business operation to the appropriate model type. In the absence of guidance on how to do this, business analysts will tend to use the model type and tool with which they are most familiar, and will tend to create a single model rather than multiple model types. This is how we end up with cases and decisions modeled as incomprehensible BPMN models, or processes being modeled as (non-standard) rule flows combined directly with DMN decisions within a DM tool. The solution to this is straightforward, although not necessarily easy: better training, mentoring and support of business analysts on the use of all three standards together. This is why I advocate a combined business automation center of excellence rather than centres for each skill or product: there needs to be a source of knowledge on how to appropriately combine model types (standards) and related technologies when analyzing business operations and making recommendations for improvements. This should include training on the three standards and how they relate to each other, but also specific use cases and examples of why to use one model type over another for a given scenario. For example, a CMMN model may manage the stages of an overall operation, with BPMN models used to drill into specific functional areas, and DMN models invoked from BPMN for repeatable decisions. Or a BPMN model may manage an end-to-end process, and call CMMN models for exception handling or other knowledge work activities.

The second challenge is that of model understandability by the broader business audience within an organization. The triple crown modeling standards are intended to bridge between business and IT by providing graphical representations of business operations that can be understood by business people while being directly executable for automation purposes; although often used by business analysts and developers, in their simpler forms they can be used as documentation and communication of the business operations to everyone from executives to front-line workers. This type of simplified communication is much more difficult when you have multiple interlinked models with three distinct model types. The viewers need to be able to understand enough BPMN to make sense of a process model, including the fact that “case task” symbol means they need to drill into a CMMN case model for that activity; then, they need to understand enough CMMN to make sense of the linked case model. Same goes for linking from a BPMN or CMMN model to DMN via a decision task, or linking from a CMMN model to a BPMN model. If the viewers don’t understand all three model types and how they interlink (much less why to interlink them at any particular point), the models become less useful as a broader communication tool. The solution to this second challenge is much less straightforward. It’s difficult to mandate or even motivate training on these standards for an entire organization: for business analysts, it’s an integral part of their job, but for everyone else, it’s just another thing that they have to learn but may not see the value. The best solution may be for business analysts within an organization, in conjunction with the business automation center of excellence, to create a simplified template for the three model types that they can use for communication purposes. Not perfect, but don’t let perfect be the enemy of good (enough).

Watch Trisotech’s Presentation at DecicionCAMP 2020

Watch now
Blog Articles

Sandy Kemsley

View all

From Project to Program: Expanding Across the Organization

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

From Project to Program: Picking Your Next Project

Blog

By Sandy Kemsley

(Read Time: 7 Minutes)

From Project to Program: Post-Implementation Review

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Building Incentives Into Processes

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

Discovering Processes In Unusual Places

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Foiling BEC Fraud With Better Distributed Processes

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Better Process Analysis Using Analytical Techniques

Blog

By Sandy Kemsley

(Read Time: 10 Minutes)

Understanding the “Why”, not just the “How”, of the BPMN-CMMN-DMN Triple Crown

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Designing Loosely-Coupled Processes to Reduce Fragility

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

The Changing Nature of Work

Blog

By Sandy Kemsley

(Read Time: 4 Minutes)

The Case for a Business Automation Center of Excellence

Blog

By Sandy Kemsley

(Read Time: 4 Minutes)

Designing Processes for Agility

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Conway’s Law and End-To-End Business Processes

Blog

By Sandy Kemsley

(Read Time: 4 Minutes)

The Need for Goal Alignment

Blog

By Sandy Kemsley

(Read Time: 4 Minutes)

previous arrowprevious arrow
next arrownext arrow
Slider
All Blog Articles

Read our experts’ blog

View all

Slider
Bruce Silver's Blog - CMMN Method and Style - Part 2
Bruce Silver
Blog

CMMN Method and Style – Part 2

By Bruce Silver

Read Time: 8 Minutes

Last month I provided a brief overview of the Case Management Model and Notation (CMMN) standard.

As it does for BPMN, Method and Style provides CMMN with additional diagrammatic conventions aimed at making the logic understandable from the printed diagrams alone. These conventions are formulated as “style rules” that can be applied as validation in a CMMN tool, such as Trisotech Case Modeler.  As described in that post, CMMN’s event-condition-action (ECA) style defines through declarative logic flexible patterns of case behavior that can be fully automated on a CMMN engine.  The problem for most modelers is that the detailed logic depends on case variables and conditional expressions that are typically delegated to programmers and in any case do not appear in the case diagram.  Method and Style conventions make them visible.

In CMMN’s ECA style, the triggering event is a lifecycle state transition of a task or stage (e.g., start, complete, exit), milestone (e.g., occur), or file item (e.g., create, update).  The condition is a Boolean expression of case variables (file items).  The action is enablement or termination of a plan item.  In the diagram, enablement is signified by a white diamond shape, called a sentry, on the boundary of the triggered plan item.  The sentry is connected to the triggering item by a dash-dot connector called an ON-part link, labeled with the triggering event, such as complete.  In similar manner, termination is signified by a black sentry.  The condition is called the sentry’s IF-part, an expression of case variables (file items).  The rules of the spec do not describe how the condition – if there is one – is made visible in the diagram, but Method and Style provides a way.  The ON-part determines when the action occurs; the IF-part determines whether it occurs.

For example, in the diagram below, task b is enabled when task a is complete.  Here there is no IF-part, i.e., the condition is true by default.

BPMN Method and Style has the concept of an activity end state, meaning how did the activity end, successfully or in some exception state?  The end state names, typically Adjective or Noun-Adjective, are the labels of the gates on an XOR gateway following the activity.

For example, the BPMN diagram above means that task a has end states “OK”, leading to task b, and “Exception”, leading to task c.  CMMN Method and Style borrows this idea, with the task end state indicated by the sentry label of an entry condition triggered by the complete event of another plan item.

Here, CMMN task a again has end states “OK”, leading to task b, and “Exception”, leading to task c.  In CMMN Method and Style, the end state of a task is captured in an implicit variable [taskname].end, and here the sentry label represents the entry condition’s IF-part expression, a Boolean.  When the ON-part link – the dash-dot connector – from the triggering plan item is labeled with the complete event, the sentry label is visual shorthand for the full IF-part expression,

[triggering task].end = [sentry label]

The expression syntax depends on the expression language employed.  The syntax I use is FEEL, which is the default in the Trisotech tools.

A milestone is a plan item signifying an achieved state of a stage in the case.  Like task end states, milestones are used in Method and Style to signify the end state of a stage, determining what happens next (or what is possible to happen next).  Unlike task end states, which are exclusive, more than one milestone in a stage may be achieved.  In Method and Style, global variable Milestones contains the list of all case milestones that have been achieved, in the format [stagename].[milestone name].  Similarly to the example above, when completion of a stage determines what happens next, a sentry labeled with the name of a milestone in the triggering stage is visual shorthand for the FEEL IF-part expression,

list contains(Milestones, [stagename].[milestone name])

Let’s take a look at a few of the style rules.  From the above examples you see that labels play a key role.  In the spec, executable CMMN references elements by ids, which are not visible, and pays little attention to labels, which are.  Many style rules require labels on CMMN elements and ascribe particular meaning to them, as we saw above with sentry labels signifying the IF-part condition.  The label of a plan item signifies its name, which must be unique in its context.  For example, style rule 0010 checks for this:

In the diagram on the left, the stage and its enclosed task have the same name, Registration.  This is a style error.  The diagram on the right is correct.

In the spec, dotted line connectors called associations are optional annotations with no operational semantics, but Method and Style may require them, in order to make the case logic visible from the diagram.  For example, the trigger of a timer event listener (similar to a timer intermediate event in BPMN) has no official representation in the diagram, so Method and Style uses a directional association labeled with an event of the triggering item.  Without this connector, the trigger is assumed to be activation of the containing stage.  If the connector is present, style rules require the event label:

The diagram above means that Registration Stage is terminated automatically (black sentry) if it is not completed within 7 days of the actual start of task Registration.  The association labeled manual start defines the trigger of the timer.  The timer label defines its duration.  The diagram on the left is missing the event label, and thus is a style error.  If the timer event listener is missing its duration label, that is also a style error.

Other style rules resolve inconsistencies in the CMMN spec.  Style rule 0100, for example, prohibits ON-link connectors from crossing stage boundaries.  In one part of the spec, it says such links are not allowed; in another part it says they are allowed, and in the wild you often see them.  But such links do not work when a stage is rendered collapsed, and a basic principle is that the semantics should not depend on an element’s graphical rendering.  In Method and Style such links are not allowed.  The top diagram below is thus a style error; the bottom diagram is correct.

The diagram above also illustrates how milestones are used as stage end states.  Task Acceptance is enabled when Registration Stage completes in the end state “Registration OK”.  The sentry label is visual shorthand for the FEEL IF-part expression

list contains(Milestones, "Registration Stage.Registration OK")

And note also that the milestone Registration OK is activated when the task Registration completes in the task end state “OK”.

Still other style rules guard against infinite loops.  The hashtag symbol indicates a plan item is Repeatable,  meaning when it completes a new instance becomes Available immediately if its Repetition Rule is true.  Like IF-part expressions, Repetition Rules are Boolean expressions of case variables (file items) that are normally invisible in the diagram.  Method and Style requires a text annotation to reveal the Repetition Rule; otherwise the rule is assumed to be true by default.  Thus if a Repeatable task or stage is not manually activated, has no entry condition, and does not have a text annotation indicating a Repetition Rule, the new Available instance will become Active as soon as the previous one completes, an infinite loop that prevents completion of its containing stage.

In the left diagram above, task Registration is an infinite loop, a style error.  In the center diagram, Registration is ok, since it is manually activated, and task Acceptance is ok as well, since it has an entry condition.  In the right diagram, Registration is ok as well, since it has a Repetition Rule that prevents an infinite loop.

A final style rule example is intended to eliminate deadlocks caused by zombie states, when a stage is completed manually before its expected end state milestones are set.  The rule says that if a stage has multiple milestones tested by the IF-parts of complete links, it should contain a single Required milestone triggered by all those milestones, in order to ensure proper stage completion.  A stage may not be manually completed unless all of its Required elements are Completed.  The example below illustrates:

In the top diagram, Registration Stage has two milestones tested by complete links, and one leading to exit.  Since no plan items are Required, it is possible for a case worker to manually declare Registration Stage complete without achieving any of the milestones, and in that case there is no next step available.  Style rules flag this with a warning.  The bottom diagram is correct.  Here achieving either milestone New registration or Existing registration sets the Required milestone Registration completed.  The stage may not complete unless the Required milestone is achieved, preventing the zombie state.

If all of this looks wildly unfamiliar, that’s because it is!  But help is on the way.  My book CMMN Method and Style explains it all at length, and it is available on Amazon.  You can play around with CMMN by starting a free trial.

Blog Articles

Bruce Silver

View all

Repeating Activities in BPMN

Blog

By Bruce Silver

(Read Time: 6 Minutes)

Using Messages in Executable BPMN

Blog

By Bruce Silver

(Read Time: 6 Minutes)

XML and JSON in DMN Models

Blog

By Bruce Silver

(Read Time: 7 Minutes)

BPMN: Database Operations with OData

Blog

By Bruce Silver

(Read Time: 12 Minutes)

BPMN 101: What Is a Process?

Blog

By Bruce Silver

(Read Time: 6 Minutes)

DMN: Dealing with Nothing

Blog

By Bruce Silver

(Read Time: 10 Minutes)

Calling Rest Services from DMN

Blog

By Bruce Silver

(Read Time: 7 Minutes)

BPMN Decoded: Data Flow

Blog

By Bruce Silver

(Read Time: 6 Minutes)

BPMN Basics: Providing Information to a Process

Blog

By Bruce Silver

(Read Time: 10 Minutes)

CMMN Method and Style – Part 2

Blog

By Bruce Silver

(Read Time: 8 Minutes)

CMMN Method and Style – Part 1

Blog

By Bruce Silver

(Read Time: 10 Minutes)

Modeling Virus Transmission on an Airplane

Blog

By Bruce Silver

(Read Time: 8 Minutes)

Using Decision Services

Blog

By Bruce Silver

(Read Time: 10 Minutes)

Use Contexts to Simplify Your Decision Models

Blog

By Bruce Silver

(Read Time: 9 Minutes)

Why BKMS?

Blog

By Bruce Silver

(Read Time: 11 Minutes)

Helping the Mortgage Industry Go Digital

Blog

By Bruce Silver

(Read Time: 12 Minutes)

BPMN Style Rules

Blog

By Bruce Silver

(Read Time: 6 Minutes)

DMN, Meet Machine Learning

Blog

By Bruce Silver

(Read Time: 12 Minutes)

Matrix Operations in DMN

Blog

By Bruce Silver

(Read Time: 15 Minutes)

Practical DMN: The Basics

Blog

By Bruce Silver

(Read Time: 8 Minutes)

previous arrowprevious arrow
next arrownext arrow
Slider
All Blog Articles

Read our experts’ blog

View all