CMMN Elements

Case Management Model and Notation (CMMN) is a standard for modeling adaptive, knowledge-intensive processes where the flow cannot be fully predefined. CMMN complements BPMN for scenarios like case management, incident handling, and investigative processes.

When to use CMMN vs BPMN: Use BPMN for well-defined, repeatable processes. Use CMMN when the sequence of activities depends on case-specific information, human judgment, or external events that cannot be predicted at design time.

Core Elements

Element	Description
Case	The top-level container for a case definition. Contains a Case Plan Model and all related case elements. A case instance is created when a new case is opened.
Case Plan Model	The root stage of a case. Contains all stages, tasks, and milestones. The case is complete when the Case Plan Model reaches a terminal state (Completed or Terminated).
Stage	A grouping of case elements that can be activated, deactivated, and completed as a unit. Stages can be nested. A stage is activated when its entry sentry is satisfied.
Human Task	A task assigned to a human actor. Appears in the Tasklist UI. Has lifecycle states: Available → Enabled → Active → Completed/Terminated.
Process Task	Invokes a BPMN process as part of a case. The case waits for the process to complete before the task can transition to Completed.
Milestone	A significant point in the case lifecycle. A milestone has no duration — it is either Achieved or Unavailable. Milestones are triggered by sentries.
Case File Item	A document or data item associated with the case. Can trigger sentries when its state changes (Created, Updated, Deleted).
Sentry	A condition that guards a transition. A sentry consists of an On-Part (event trigger) and/or an If-Part (FEEL expression). When satisfied, the sentry triggers its associated transition.

Case Lifecycle


  Case Instance Created
         |
         v
  ┌──────────────────────────────────────────┐
  │           CASE PLAN MODEL                │
  │                                          │
  │  [Stage: Investigation]                  │
  │    ├── Human Task: Review Report         │
  │    ├── Human Task: Interview Witness     │
  │    └── Milestone: Report Reviewed        │
  │                                          │
  │  [Stage: Resolution]  ◄── activated when │
  │    ├── Human Task: Decide Action         │  milestone achieved
  │    ├── Process Task: Notify Customer     │
  │    └── Milestone: Case Resolved          │
  │                                          │
  └──────────────────────────────────────────┘
         |
         v
  Case Completed / Terminated

Sentry: Entry and Exit Criteria

Sentries are the key concept that makes CMMN adaptive. They are attached to plan items (stages, tasks, milestones) and define the conditions under which transitions occur.

Entry Criterion (EntryCriterion)

An entry criterion defines when a plan item becomes available or active. It consists of:

On-Part: An event from another plan item (e.g., "when Task A completes")
If-Part: A FEEL condition (e.g., caseRisk = "high")

Exit Criterion (ExitCriterion)

An exit criterion defines when a stage or task should be forcibly terminated. Useful for timeout or cancellation scenarios.

<!-- Sentry: activate Resolution stage when milestone is achieved -->
<sentry id="sentry1">
  <planItemOnPart sourceRef="milestone_reportReviewed">
    <standardEvent>occur</standardEvent>
  </planItemOnPart>
  <ifPart>
    <condition>=caseRisk = "high"</condition>
  </ifPart>
</sentry>

Example: Fraud Investigation Case

The following CMMN case plan models a fraud investigation workflow where the sequence of activities depends on the investigator's findings:

<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://www.omg.org/spec/CMMN/20151109/MODEL"
             targetNamespace="http://priostack.com">
  <case id="fraudInvestigation" name="Fraud Investigation">
    <casePlanModel id="cpm" name="Fraud Investigation Plan">

      <!-- Stage 1: Initial Assessment -->
      <stage id="stage_assessment" name="Initial Assessment">
        <planItem id="pi_reviewAlert" definitionRef="task_reviewAlert" />
        <planItem id="pi_gatherEvidence" definitionRef="task_gatherEvidence" />
        <planItem id="pi_milestone_assessed" definitionRef="milestone_assessed">
          <entryCriterion sentryRef="sentry_allTasksDone" />
        </planItem>
        <humanTask id="task_reviewAlert" name="Review Fraud Alert">
          <defaultControl>
            <manualActivationRule><condition>false</condition></manualActivationRule>
          </defaultControl>
        </humanTask>
        <humanTask id="task_gatherEvidence" name="Gather Evidence" />
        <milestone id="milestone_assessed" name="Assessment Complete" />
        <sentry id="sentry_allTasksDone">
          <planItemOnPart sourceRef="pi_reviewAlert">
            <standardEvent>complete</standardEvent>
          </planItemOnPart>
        </sentry>
      </stage>

      <!-- Stage 2: Resolution (activated after assessment) -->
      <stage id="stage_resolution" name="Resolution">
        <entryCriterion sentryRef="sentry_assessmentDone" />
        <planItem id="pi_decide" definitionRef="task_decide" />
        <planItem id="pi_notify" definitionRef="task_notify" />
        <humanTask id="task_decide" name="Decide on Action" />
        <processTask id="task_notify" name="Notify Customer">
          <processRefExpression>customer-notification-process</processRefExpression>
        </processTask>
      </stage>

      <sentry id="sentry_assessmentDone">
        <planItemOnPart sourceRef="pi_milestone_assessed">
          <standardEvent>occur</standardEvent>
        </planItemOnPart>
      </sentry>

    </casePlanModel>
  </case>
</definitions>

Task Lifecycle States

State	Description
`Available`	The task exists in the plan but has not yet been enabled.
`Enabled`	The task can be manually started (manual activation rule applies).
`Active`	The task is currently being worked on.
`Completed`	The task finished successfully.
`Terminated`	The task was cancelled by an exit criterion or manual action.
`Failed`	The task ended in an error state.
`Suspended`	The task is temporarily paused (parent stage suspended).