Common Modeling Challenges in CMMN

Never assume a case plan can be both adaptive and predictable by design. This is the single most dangerous assumption in CMMN modeling—and the root of 90% of modeling failures.

When you treat a CMMN case like a rigid BPMN flow, you’re not modeling a case—you’re constructing a control tower for chaos. The flexibility that makes CMMN powerful becomes a liability when entry criteria, sentries, and task dependencies are defined too early or too rigidly.

Over years of working with healthcare, legal, and insurance teams, I’ve seen case models collapse under their own complexity—not from poor execution, but from poor design. The core issue? A lack of clarity about what makes a case a case. This chapter walks you through the most common CMMN modeling errors, backed by real examples and remediation strategies.

You’ll learn how to draw clear case boundaries, simplify logic without losing adaptability, and align your modeling with actual business behavior—not imagined workflows.

Common CMMN Modeling Errors

1. Unclear Case Boundaries

One of the most frequent CMMN modeling errors is treating every task as part of a single, monolithic case. This leads to sprawling, unreadable case plans that no one can maintain.

Case boundaries should reflect the actual decision-making scope—what a single team or individual is responsible for resolving.

Ask this: If a case fails, who owns the outcome? The answer defines the boundary. If multiple teams are involved, consider breaking it into sub-cases or using CMMN’s case reference capabilities.

Real example: In an insurance claims investigation, one team handles fraud checks, another handles medical records. Modeling them as one case creates unnecessary interdependencies. Instead, use a parent case with child cases for each investigative path.

2. Over-Reliance on Entry/Exit Criteria Logic

Entry and exit criteria are powerful, but they’re not magic. When criteria are too complex, they become opaque and brittle.

I’ve seen models where criteria involve complex nested conditions: “The claim must be submitted, the patient must be under 65, and the doctor must have a valid license, and the treatment must be on the approved list, and…”

This isn’t modeling flexibility—this is enforcing a rigid checklist. The real risk? A single change in business policy invalidates the entire case logic.

Fix: Decompose complex logic into reusable decision tables or delegate to a DMN (Decision Model and Notation) component. Keep entry/exit criteria focused on high-level conditions like “Claim submitted and approved by supervisor”.

3. Misuse of Stages and Milestones

Stages in CMMN represent logical progress points, not workflow steps. They should reflect business-level transitions, not technical milestones.

Common mistake: Using “Stage 1: Document Collection,” “Stage 2: Review by Legal,” “Stage 3: Decision” without defining what success looks like for each. This creates ambiguity.

Instead, name stages by outcome: “Document validation complete,” “Legal review completed,” “Settlement terms agreed.” This forces the modeler to think in terms of business events—not task lists.

Checklist: For every stage, ask: What business condition triggers it? What external event confirms it has ended?

4. Over-Engineering Sentences

Sentries are CMMN’s way of responding to events dynamically. But when overused, they turn a flexible model into a reactive mess.

Consider a model where every task has multiple sentry conditions: “If task is overdue, send alert.” “If no response in 48 hours, escalate.” “If risk score exceeds 70, pause.”

These may seem logical, but they create dependency chains that are impossible to trace. The model becomes a black box.

Best practice: Limit sentry logic to critical, high-impact events. Use one sentry per stage or task, and keep it simple. Example: “If no progress in 72 hours, trigger escalation.”

5. Confusing CMMN with BPMN

This is not a rare error—it’s a culture problem. Many practitioners apply BPMN thinking to CMMN: “We need to sequence everything.”

But CMMN is not about control flow. It’s about constraint-based planning. The goal isn’t to define “what happens next”—it’s to define “what can happen next.”

Example: In a customer dispute case, you shouldn’t model “Call customer → Review complaint → Notify legal” as a fixed sequence. Instead, model “Customer communication” and “Legal review” as optional tasks that can be triggered by events. Let the case worker decide the path.

6. Ignoring Case File Management

The case file is the memory of the case. Without proper structure, critical data becomes scattered across tasks and timelines.

Common error: Leaving case file elements undefined. No ownership, no versioning, no data access rules.

Fix: Define what data must be recorded in the case file. Assign ownership to specific tasks or stages. Use case file elements to store key artifacts: claim forms, medical reports, emails.

Example: In a hospital discharge planning case, the case file should include: patient vitals, medication list, family contact, and discharge plan document.

CMMN Best Practices for Real-World Success

Building a robust CMMN model isn’t about avoiding all errors—it’s about making intentional choices. Here’s how to stay aligned with CMMN’s core philosophy: adaptive, knowledge-driven work.

• Start with the case goal, not the task list. Ask: What is the single outcome this case must achieve? Everything else follows.
• Use stages to reflect business milestones. Not all stages are equal—some represent decisions, others represent data collection.
• Delegate complex logic to DMN. Don’t embed business rules in CMMN criteria. Use DMN decision tables for policy-driven decisions.
• Limit sentries to high-impact triggers. Escalation, deadline, risk detection—these are the only events worth modeling.
• Define case file early. Sketch the data structure before adding tasks. What data is essential? Who needs access?

When CMMN Fails: Red Flags

If your CMMN model feels like a BPMN diagram with “maybe” decisions, it’s likely misapplied. These are signs you may be using the wrong tool:

• You’re forced to define every task in a fixed sequence.
• Entry criteria involve more than 2–3 conditions.
• Sentries are triggered for every minor task.
• Task dependencies are based on completion, not events.
• There’s no clear distinction between “to do” and “in progress” states.

If any of these apply, pause. Re-evaluate the scenario. Is this truly adaptive work? Or is it a structured process that belongs in BPMN?

Frequently Asked Questions

What is the most common CMMN modeling error?

Over-segmenting or under-segmenting the case boundary. Teams either try to model every possible task in one case or split cases too granularly, leading to poor traceability and management overhead.

Can I use BPMN and CMMN together in the same process?

Yes. In fact, it’s common. Use BPMN for predictable flows (e.g., order processing), and CMMN for the exceptions or investigations that arise—like fraud checks or disputes. CMMN can be embedded as a subprocess or referenced from BPMN.

How do I decide if a scenario needs CMMN or BPMN?

Ask: Is the path predictable? If yes, BPMN. If the path depends on decisions, events, or knowledge, CMMN. Example: Loan approval (BPMN) vs. customer complaint investigation (CMMN).

Why does my CMMN model keep breaking when business rules change?

Because you likely embedded business rules directly into entry/exit criteria or tasks. Use DMN to externalize decision logic. This keeps your CMMN model stable and reusable across scenarios.

What should I include in a CMMN case file?

Only the data essential to decision-making. Common items: customer information, claim documents, medical reports, communication logs, risk scores, and decision records. Avoid storing raw emails or duplicate data.

How can I validate a CMMN model before deployment?

Use model validation rules: ensure all tasks have clear triggers, entry/exit criteria are unambiguous, sentries are event-based, and case file elements are properly defined. Run simulations with real-world scenarios to test adaptability.