Dissecting the Case Plan Model

Most diagrams you see online show a clean, linear case plan with neatly aligned tasks and stages. But here’s what they never tell you: that structure is a trap. It implies predictability, when in reality, the power of CMMN lies in its ability to handle unpredictability. I’ve seen countless models fail during stakeholder reviews not because of poor logic, but because they misrepresented the true nature of a case plan.

The real test of a CMMN case plan isn’t how it looks on paper—it’s how it behaves when events happen out of sequence, when stakeholders take different paths, or when data arrives late. A well-structured case plan doesn’t dictate flow; it responds to change.

This chapter walks you through the anatomy of a CMMN case plan model—stages, tasks, milestones, case files, and sentries—not as isolated elements, but as interconnected components that evolve with the case. You’ll learn how to avoid common modeling pitfalls, align structure to business intent, and apply principles that make your models both readable and operational.

Understanding the CMMN Case Plan Model

The CMMN case plan model is not a flowchart. It’s a living structure that reflects how knowledge work unfolds in real time. Unlike BPMN, which assumes a fixed path, CMMN embraces uncertainty. The model doesn’t force tasks into order—it guides when and how tasks become active based on conditions.

At its core, the case plan model consists of three layers: structure, behavior, and data. Structure defines what exists—stages, tasks, milestones. Behavior defines when things happen—via sentries, entry criteria, and activation rules. Data is the context—case files that carry the evidence.

Think of a CMMN case plan as a playbook. It doesn’t tell the team exactly what to do. It tells them what they can do, when they can do it, and what must be true before they can proceed. That’s the essence of adaptive case management.

Core Elements of the CMMN Case Plan

Every CMMN case plan model includes the following core components. Get these wrong, and your model becomes a static diagram, not a decision-support tool.

• Stages represent logical phases in a case’s lifecycle, such as “Initial Review” or “Escalation.” They group related tasks and help structure progress.
• Tasks are atomic units of work that can be performed by a human or system. They may be optional, mandatory, or conditionally activated.
• Milestones are significant checkpoints that mark progress. They are not tasks but indicators of when a stage or the entire case is complete.
• Case Files hold the data that drives decision-making. These aren’t just fields—they’re dynamic references to documents, statuses, and metadata.
• Sentries govern activation and completion. They can be event-based (e.g., “when a document is uploaded”) or time-based (e.g., “after 30 days”).

These elements don’t exist in isolation. Their real power emerges through their relationships—and it’s these relationships that make the CMMN case plan model adaptive.

Structuring the Case: Stages and Tasks

Stages are the backbone of a case plan. They define the big picture: what phases a case goes through. But they’re not rigid. You can have overlapping stages, optional stages, or even dynamic stage creation based on case data.

I once modeled a medical review case where the path diverged based on severity. The initial stage “triage assessment” triggered two possible next stages: “routine review” or “emergency review”—both activated conditionally based on a risk score.

That’s the key: stages are not just containers. They are conditional gateways. You can model them as sequential, parallel, or even nested within sub-cases.

Modeling Task Dependencies with Sentries

Tasks in CMMN don’t run on a timeline. They activate based on sentries—conditions that monitor events, data, or time.

Consider a case file with a field “document_received.” A task like “review documentation” can only activate when the sentry “document_received = true” is met. This is event-driven control at its best.

But here’s where most models fail: they list sentries as simple checkboxes. The real challenge is modeling complex sentries—combinations of conditions, data values, and event sequences.

For example:

IF (document_type = "claim") AND (date_submitted <= today - 7 days)
   AND (status = "pending")
THEN activate "priority review task"

This level of logic should be embedded in the sentry condition, not left to interpretation.

Milestones and Progress Tracking

Milestones are not just visual cues. They’re critical for monitoring, reporting, and governance. They signal when a stage is complete—or when a case has reached a decision point.

A common mistake is treating milestones as afterthoughts. But they should be defined at the start, based on business outcomes. In a customer support case, a milestone like “resolution confirmed” should only be set when a customer reply confirms satisfaction.

Use milestones to measure performance. Track how long it takes to reach “initial assessment complete” versus “final decision reached.” These aren’t just labels—they’re KPIs.

Example: Milestone in a Claim Processing Case

Milestone	Trigger Condition	Used for
Claim Received	Case file: “claim_received_date” is set	Start clock on processing
Assessment Complete	“risk_assessment” = “completed”	Trigger next review stage
Payment Approved	“approval_status” = “approved” AND “payment_date” set	Close case and notify

This table shows how milestones are not just markers—they are operational checkpoints tied to data and decisions.

Managing Case Files: The Data Backbone

Case files are where the real work happens. They contain the data that defines the case, drives sentries, and informs decisions.

Don’t model case files as simple lists. Treat them as a dynamic data model with:

• Item references (e.g., “attached document 1”) that link to external content.
• Dynamic attributes that change based on user input or system events.
• Relationships to other case files or external systems (e.g., customer database).

For example, in a healthcare intake case, the case file might include:

• Patient ID
• Referral source
• Eligibility status (auto-checked)
• List of previous visits

These are not static. They evolve. A task like “verify eligibility” updates the case file. That change then triggers the next sentry.

The CMMN case structure must reflect that data flow. If the case file is missing, the model is incomplete.

Real-World Modeling: Getting It Right

Let me share a lesson from a real insurance modeling project. A team built a CMMN case plan for claim review. They used a linear path: “submit → assess → approve.” But when events occurred—like missing documents or fraud alerts—the model failed. Why? Because they didn’t model the conditional activation of tasks.

After refactoring, we introduced sentries based on:

• “Document quality = high” → activate “standard review”
• “Document quality = low” → activate “document clarification task”
• “Fraud score > 70” → activate “fraud investigation task”

Now, the case plan responded to context, not just sequence. That’s what makes the CMMN case structure adaptive.

Remember: a case plan model is not a process flow. It’s a decision engine. The goal is not to control work—but to enable it.

Common Pitfalls and How to Avoid Them

• Over-segmenting tasks: Breaking work into micro-tasks creates clutter. Group tasks under stages unless activation logic demands separation.
• Ignoring sentry complexity: Simple “if yes, proceed” sentries are fine, but real cases need logic trees. Use conditional expressions in sentry conditions.
• Treating milestones as decorative: Milestones must have verifiable triggers. Define them by data or events, not just time.
• Missing case file context: Every task should reference or update the case file. If a task doesn’t impact the case data, question its purpose.

Frequently Asked Questions

What’s the difference between a stage and a task in CMMN?

Stages are logical groupings of work—like phases in a case’s lifecycle. Tasks are the actual work items that can be performed. A stage can contain multiple tasks, and tasks can be activated conditionally based on sentries.

Can I model a CMMN case plan without stages?

Yes, but it’s not recommended. Stages provide structure, improve readability, and support progress tracking. Without stages, the case plan becomes a flat list of tasks, which is harder to manage and scale.

How do sentries work in practice?

Sentries define when a task or stage becomes active. They can monitor events (e.g., “when a document is uploaded”), time (e.g., “after 24 hours”), or data conditions (e.g., “when status = pending”). They’re the glue between data and action.

What’s the best way to model case files?

Start with the data that matters. Identify who needs to access it, when it changes, and how it affects task activation. Use case file items to represent documents, status fields, and external references. Ensure all tasks update or read from the case file.

Why should I use CMMN instead of BPMN for my case model?

BPMN is ideal for predictable, structured processes. CMMN excels in unpredictable, knowledge-intensive cases. Use CMMN when decisions depend on expert judgment, information arrives asynchronously, or the path isn’t known in advance.

Can I combine CMMN with BPMN and DMN?

Absolutely. In a hybrid model, use CMMN to manage the overall case, BPMN for structured subprocesses (like payment processing), and DMN for decision logic (like risk scoring). CMMN acts as the orchestrator—BPMN and DMN as tools within it.