Design Thinking for CMMN Modelers
Most modelers fail not from lack of tools, but from misunderstanding the core mindset required to approach adaptive processes with clarity. The real prerequisite isn’t notation knowledge—it’s the ability to hold ambiguity with purpose. CMMN design thinking isn’t a rigid framework; it’s a disciplined way of listening to stakeholders, identifying patterns in chaos, and translating those insights into a model that can evolve.
I’ve spent over two decades helping teams model complex cases—insurance claims, legal reviews, patient intake—where no two cases follow the same path. The moment you assume a linear flow, you’ve already lost. CMMN design thinking starts by asking: what’s truly unpredictable here? What decisions are made in real time? And how can the model reflect that autonomy?
This chapter equips you with a proven, actionable approach to transform fragmented stakeholder stories into structured, maintainable case models. You’ll learn how to apply CMMN analysis to extract key triggers, define meaningful stages, and design flexible decision points—all while preserving human judgment. This is not about automation; it’s about alignment between process and expertise.
Embrace the Narrative First
Start not with a diagram, but with the story. Every case begins with a narrative—often told in fragments, jargon, or emotional language. Your job isn’t to clean it up. It’s to decode it.
Ask three guiding questions: What happens when this event occurs? Who decides what next? Where does the process pause or change direction?
For example, in a legal intake case, a stakeholder might say: “If the client has a criminal record, escalate to a senior attorney.” This isn’t a task—it’s a condition. That’s where CMMN analysis begins: identifying event-driven logic, not sequence.
Steps to Extract Insight from Stakeholder Narratives
- Record verbatim the stakeholder’s description—don’t summarize.
- Tag key triggers (e.g., “if,” “when,” “after”) and underline decisions.
- Map to CMMN elements: Is this an event? A task? A stage? A sentry?
- Reconstruct the flow using stages and milestones, not steps.
This isn’t analysis in the traditional sense. It’s interpretation with intent.
Define the Case Lifecycle: Stages Over Steps
Traditional process models start with “begin” and end with “end.” CMMN models start with a case state and evolve through stages. A stage isn’t a task—it’s a phase of progress.
Consider a medical intake case. The stages might be: Initial Review → Eligibility Check → Document Collection → Risk Assessment → Approval. Each stage has entry and exit criteria—often tied to events.
Use this table to compare staging vs. step-based thinking:
| Aspect | Traditional Process (BPMN) | CMMN Case Modeling |
|---|---|---|
| Structure | Linear path | Adaptive stages |
| Decision Point | Gateways in sequence | Sentries on stage entry/exit |
| Control | Predefined flow | Event-driven, human-led |
| Flexibility | Limited | High |
Stages are not milestones—they are containers for work. They help you group related tasks and decisions while allowing flexibility in execution order.
Design with Sentries, Not Sequences
One of the most common mistakes in CMMN modeling is treating sentries like simple conditions. They’re not. They are triggers. They respond to events, not timelines.
For example: “The case moves to the Risk Assessment stage when all documents are uploaded and verified.” This is a sentry condition. It doesn’t say “after 24 hours”—it says “when.” That’s the difference between a timer and an event.
Use the following checklist when defining sentry conditions:
- Is the trigger event-based? (e.g., document uploaded, approval denied)
- Is the condition tied to data? (e.g., “if total claim amount > $50K”)
- Can the event happen multiple times? (Yes—sentries can be re-evaluated)
- Does the model allow backward transitions? (Yes—CMMN supports this)
When a sentry is met, the stage becomes active. The model doesn’t force flow—it enables action.
Apply the Case Modeling Approach: A Step-by-Step Guide
Here’s how I walk teams through CMMN analysis for a real-world scenario: a high-risk insurance claim.
- Identify the case type: “High-Risk Claim Review” — a case, not a process.
- Extract key events: “Claim submitted,” “Document received,” “Suspicious activity detected,” “Senior adjuster assigned.”
- Define stages: Preliminary Review → Document Verification → Risk Assessment → Senior Review → Resolution.
- Assign sentries:
- Stage 1 → Stage 2: “All required documents are uploaded and verified.”
- Stage 2 → Stage 3: “Suspicious activity detected OR claim amount > $100K.”
- Stage 3 → Stage 4: “Risk score ≥ 70.”
- Define case file items: Claim ID, Submitted Date, Claim Amount, Risk Score, Evidence Files.
- Validate: Does the model reflect real decisions? Can it handle exceptions?
This is CMMN analysis in practice: not about making every path explicit, but about enabling the right decisions at the right time.
Balance Control and Autonomy
The most powerful CMMN models don’t eliminate choices—they frame them. When a stakeholder says “we need flexibility,” they don’t mean “no rules.” They mean “we want to adapt based on context.”
Use milestones not to constrain, but to signal progress. A milestone like “Document Verification Complete” is a checkpoint, not a gate. It can be reached in many ways—some faster, some slower. But it’s visible to all.
Remember: you’re not designing a machine. You’re designing a space where experts can work. The model’s role is to support, not dictate.
Frequently Asked Questions
What’s the difference between CMMN design thinking and traditional process analysis?
CMMN design thinking focuses on adaptive, event-driven workflows. It prioritizes human judgment and dynamic decision-making. Traditional analysis assumes a fixed sequence and often relies on pre-defined paths, which fail when exceptions arise.
How do I handle conflicting stakeholder inputs during CMMN analysis?
Don’t try to resolve conflict immediately. Map all perspectives. Then ask: which condition triggers the next stage? Use sentry logic to represent multiple possible paths. You’re not choosing between opinions—you’re modeling how decisions are made.
Can CMMN design thinking work for simple cases?
Yes. Even simple cases benefit from structured stages and sentries. It reduces errors, improves visibility, and makes future expansion easier. A simple case today may become complex tomorrow.
How often should I revisit the case model after deployment?
At least quarterly. Use feedback from case managers, audit logs, and exception reports. If you see repeated deviations from the model, it’s a signal to re-evaluate sentries or stages. CMMN models must evolve.
What role does the case file play in CMMN design thinking?
The case file is the central repository for data. All decisions and actions depend on it. During analysis, identify which items are critical: e.g., “Claim Amount,” “Client Criminal History,” “Document Uploads.” These inform sentry conditions and help maintain consistency.
Is CMMN design thinking only for large enterprises?
No. Any organization handling knowledge-intensive, unpredictable work benefits—healthcare, legal, IT support, compliance. The principles scale down to single teams. The key is recognizing when flexibility is needed, not assuming a fixed path.
