CMMN Method and Style

by Bruce Silver
Publisher: Cody-Cassidy Press
Publication Date: May 2020
Pages: 130

Case management is a branch of business process management dealing with unstructured and event-driven processes. CMMN is a business-oriented diagramming language standard for creating case models, for both case logic description and execution. Following the author’s popular BPMN Method and Style and DMN Method and Style, this book shows how to use CMMN to create case models in which the logic is both clear from the printed diagrams and executable on a business automation platform.

Unlike BPMN for structured processes, which adopts the familiar look of swimlane flowcharts, CMMN’s diagrams are unfamiliar to most modelers. In addition, CMMN logic is declarative, each task and stage in the model independently defining its own prerequisites. Aimed at business users, the book explains how to use the diagramming notation in a range of modeling styles, including:

  • User-driven, in which what happens next is determined primarily by knowledge worker decisions
  • Event-condition-action (ECA), in which what happens next is determined primarily by business events
  • Hierarchical, in which CMMN stages are used as exclusive states of the case, with a top-level diagram describing the overall case logic and child-level diagrams describing the logic of each stage.

On top of the rules of the language defined in the specification, the author adds additional conventions called Method and Style, aimed at ensuring the case logic is clear from the printed diagrams. Many details needed to understand the logic are visible only to modelers with access to the design tool, not to stakeholders in the business who see only what is in the printed diagrams. Method and Style prescribes various additional connectors and labeling conventions that make these logic details visible to all. These conventions are formulated as “style rules” that can be validated in a CMMN tool.

The book provides detailed explanation of CMMN’s declarative logic patterns, illustrated by examples from the field of Social Care. In addition, it provides an exhaustive list of CMMN Method and Style patterns together with their more familiar BPMN Method and Style equivalents.

The book is useful for modelers who need to go beyond BPMN’s structured process constraints and for implementers who are interested in using this standard language in their business automation offerings.


Those familiar with my past writings may be surprised that I have written a book on the Case Management Model and Notation (CMMN) standard, because when CMMN was launched in 2014, I was unenthusiastic and vocal about it. Business process modeling already had a standard – BPMN 2.0 – that was widely adopted by both business and technical modelers. Why did we now need a different one? CMMN’s creators maintained that it was necessary because there are many kinds of processes that BPMN is unable to handle. Although BPMN could have been tweaked to handle them, those tweaks never happened. In my opinion, they never will; the BPMN 2.0 spec appears to be forever frozen in stone.

Actually, CMMN’s backers have a valid point. BPMN does have limitations, and in my BPMN Method and Style training we discuss them. Those limitations mostly stem from the fact that BPMN’s conception of a process is quite narrow, much narrower in fact than that of BPM Architecture and most other areas of business process management. For example, many of the “processes” listed in APQC’s Process Classification Framework are not what BPMN would call processes, and many cannot be modeled in BPMN at all. CMMN, on the other hand, could handle them. That’s reason number one for my change of heart. Instead of describing the logic procedurally – following a defined sequence of steps – CMMN logic is declarative, each case element independently defining its own prerequisite conditions. That gives it great flexibility, but makes the logic harder to communicate clearly.

A second reason was the observation that leading innovators in business process technology are now beginning to adopt and promote CMMN. For example, Trisotech’s Digital Automation Suite uses CMMN in conjunction with BPMN and DMN to create a business-friendly model-driven platform based entirely on industry standards. Also, at the annual bpmNEXT conference1 that I host together with Nathanial Palmer of, Flowable’s CMMN-based demos2 have walked off with the Best in Show award two years in a row. And in the past year, FICO, a leading decision management vendor, has made CMMN a key part of its solution development methodology, called xDRAW.3

After years of relative obscurity, CMMN is finally attracting the attention of leading technology innovators, completing the triad of business modeling and automation standards from the Object Management Group (OMG) – BPMN (process modeling), DMN (decision modeling), and CMMN (case modeling). Trisotech, Flowable, and FICO are all basing their business automation projects on that triad.

Method and Style

Once I accepted CMMN’s rationale, I could see that it was badly in need of a book. You cannot learn a modeling language from the spec, which is written for tool vendors, and a quick check of revealed zero CMMN books in print. Moreover, CMMN was in need of Method and Style as well, an approach I developed over a decade ago for BPMN and have since applied to DMN. Whereas the requirements specified in OMG’s business modeling standards emphasize precise execution semantics, modelers need something more: the ability to communicate the underlying logic to all stakeholders from the diagrams alone, without defining execution-related details usually left to programmers. That’s what Method and Style tries to provide.

Method and Style is a set of modeling conventions layered on top of the official rules of the standard. Created for non-executable models defined by business users, Method and Style encourages models that communicate the logic clearly and completely through the printed diagrams alone. Although all three of OMG’s business automation standards in theory claim two objectives – visual communication of the model logic through diagrams and tables, and direct execution of the model logic on an automation engine – the rules of the specs, in reality, concern only the latter.

Having delivered BPMN training since 2007, I know that just a tiny fraction of BPMN models are intended for execution. Instead they are used for process documentation, analysis, and improvement. For those users the only thing that counts is what is displayed in the diagrams. From the perspective of the spec, defining the process logic precisely requires adding variables and executable gateway expressions, details normally delegated to programmers and which do not appear in the diagrams. That often leaves the process logic ambiguous and incomplete to stakeholders without direct access to the modeling tool.

BPMN Method and Style

Method and Style takes the view that any model details important to understanding the logic must be expressed somehow in the diagrams. Thus BPMN Method and Style imposes various conventions that imply the existence of certain variables and gateway expressions simply from the labels of end events and gates. Those conventions make the process logic clear from the diagrams alone, with requiring modelers to actually define variables and executable expressions. In addition, various icons, symbols, and labels called optional in the spec are required by Method and Style. Method and Style’s conventions can be formalized as style rules – in addition to the rules of the spec – that can be applied as validation checks on the models.

CMMN Method and Style

With CMMN, the situation is similar. Making the case logic complete and unambiguous requires definition of variables and executable expressions for the entry and exit conditions of case model elements (called plan items), details that normally are not displayed in the diagrams. CMMN Method and Style applies conventions that imply the existence of certain variables and condition expressions based on labels of diagram elements, such as milestones and sentries. With these conventions, a wide variety of case behaviors can be described unambiguously from the printed diagrams alone.

Since CMMN’s declarative logic paradigm is unfamiliar to most users, diagrams are prone to modeling errors, such as tasks that repeat forever with no way to stop except manual termination, or deadlocked stages, unable to complete. Many such errors can be detected by the style rules as well.

Some tools, like those of Trisotech, provide automated model validation based on the style rules. When Method and Style’s rules are enforced by model validation, my own experience of BPMN and DMN training has shown them to greatly improve model quality and clarity. Thus, in addition to explaining CMMN from the perspective of the spec, this book explains the Method and Style conventions, including the style rules.

Writing the book also revealed occasional inconsistencies and ambiguities in the CMMN spec itself, motivating a series of discussions with both Trisotech and Flowable about what the spec actually intends and how to handle the problem areas. CMMN Method and Style reflects the consensus of those discussions.

Structure of the Book

The book explains the concepts of CMMN, its basic elements, and usage of these elements in various styles of case management models. In addition, it explains the Method and Style conventions, the reasons for them, and their representation in the diagrams.

I recommend that readers go through the chapters in order, although Chapter 8, Declarative Modeling Patterns, may serve as a helpful reference for certain behaviors shown in earlier chapters, as well as those the modeler may encounter in practice.

Chapter 1, What Is CMMN?, shows how case management fits in the business process management landscape. We describe how cases differ from the “structured” processes of BPMN and provide examples of typical case management scenarios. We then discuss how the CMMN standard came about, in many respects as a reaction to BPMN.

Chapter 2, Case Plan Elements, explains the building blocks of a CMMN diagram, or Case Plan Model. The case diagram shows the various actions that could take place in each state of the case, as well as how completion of those actions, in combination with other events, drive overall case behavior. We discuss the various types of tasks, the actions of a case, and stages, containers of the case plan elements available in a particular state of the case. In this chapter we also explain CMMN’s declarative logic paradigm, based on the lifecycle state of tasks, stages, and other model elements, as well as CMMN’s event-condition-action mechanism.

Chapter 3, Case File Model, discusses case data elements, known collectively as case file items. Not all case file items are visualized in the diagrams, but file item standard events – such as create, update, or delete – are displayed in the diagram if they trigger advancement of the case plan. We also introduce the Method and Style concept of implicit file items that capture the state of a task or milestone for use in condition expressions in event-condition-action logic.

Chapter 4, Modeling Case Logic, shows how the various diagram elements are used in combination to describe activity flow in a declarative manner. We discuss the conditions under which a CMMN task or stage starts and completes and the benefits of using BPMN and CMMN in combination. We extend BPMN Method and Style’s concept of end states to tasks and stages in CMMN, including their visual representation in the diagrams.

Chapter 5, Styles of Case Modeling, illustrates three basic styles used in CMMN models: user-driven, event-condition-action (ECA), and hierarchical. Typically, a CMMN model contains a mix of all three styles. In the user-driven style, the case advances based on manual user action, selecting from a menu of available actions such as completing or terminating a task or stage, or starting an available task or stage. In the ECA style, the case advances automatically based on declarative logic defined at design time, in which lifecycle events of plan items and file items, in combination with file item conditions, determine whether a task or stage starts, completes, or exits. In the hierarchical style, stages typically represent exclusive states of the case. The top-level diagram displays stages in collapsed form and shows the logic determining which stage is active at any time. The details of each stage are shown in hyperlinked child-level diagrams.

Chapter 6, CMMN by Example: Social Care, presents a detailed real-world example based on social care in a European country, using elements of all three case modeling styles.

Chapter 7, Style Rules, explains the Method and Style model validation rules. The style rules are not part of the CMMN spec. They are just my own recommendations, intended to (1) make the case logic clear from the printed diagrams, and (2) warn against logic that could lead to unintended behavior, such as deadlocked models.

Chapter 8, Declarative Modeling Patterns, explains CMMN’s various ECA “micropatterns” with reference to equivalent BPMN patterns using Method and Style. This chapter can be used as a reference for understanding other models in the book as well as real scenarios encountered by the modeler. Readers familiar with BPMN may want to read this chapter before Chapter 6.

Chapter 9, Executable CMMN with Method and Style, explains how executable CMMN tools can integrate Method and Style by automatically generating variables and condition expressions implied by the labels of various diagram elements.


This book would not have been possible without the efforts of Trisotech to create a tool that is not only faithful to the CMMN standard but adds support for the Method and Style conventions, including automated style rule validation. Trisotech Case Modeler was used to create the diagrams used in the book, and I urge readers to go to to request a free trial of the software.

Special thanks go to Denis Gagne, Simon Ringuette, and Maciej Swiderski, the brains behind Trisotech Case Modeler, who also provided extensive review and comments on the book drafts. I could not have wished for better partners. I also received generous review and comments from members of Flowable’s CMMN team, including Paul Holmes-Higgin, Joram Barrez, Micha Kiener, and Tijs Rademakers. Thank you all so much!

I am grateful as well to Serge Schiltz of processCentric GmbH, who contributed the Social Care scenario described in Chapter 6. I took some liberties with it, so don’t blame Serge for any discrepancy between that model and “the way it ought to work.”

Thanks also to Carol Leyba for cover design and other assistance, as always.

Bruce Silver

Pasadena, CA, May 2020