Nested Case Models and Sub-Case Strategies

When a case isn’t just a single flow—it’s a system of interconnected decisions, roles, and data, the real power of CMMN emerges through nesting. I’ve worked with dozens of enterprise-grade models where a single case plan wasn’t enough. It wasn’t just about flexibility; it was about structure within chaos.

Think of a medical disability review. The main case exists for the individual, but it branches into subcases: one for diagnostics, another for legal compliance, and a third for employer coordination. Each subcase has its own tasks, data, and lifecycle—but they’re all tied together under the parent case. That’s where nested CMMN becomes essential.

This chapter focuses on how to build and manage these hierarchical models effectively. You’ll learn how to define CMMN subcase relationships, link data across levels, and trigger activation based on real-world dependencies. The goal isn’t to automate every step—but to design models that adapt intelligently and reflect the true complexity of expert work.

Understanding the Need for Nested Case Models

Not every case is a simple linear journey. Some require parallel decision paths, independent workflows, or shared data resources. That’s where nested CMMN steps in.

Consider a legal case involving multiple parties. The lead case might include subcases for discovery, motion filing, and settlement negotiation. Each operates semi-independently but shares common data—like case files, evidence logs, and court dates.

Without nesting, you’d either over-bundle tasks into one monolithic case plan or duplicate logic across multiple models. That leads to inconsistency and maintenance nightmares.

Nested CMMN solves this by allowing a case to contain child cases—each with its own structure, case file, and activation rules. These are not parallel processes. They are subcases, deeply tied to the parent through data and control dependencies.

When to Use Nested CMMN

Not every case needs nesting. But when any of these apply, consider it:

• Multiple stakeholders manage different parts of the same case.
• Tasks in one area depend on outcomes from another, but execution isn’t sequential.
• Sub-activities involve distinct roles, documentation, and approval chains.
• Some parts of the case need to be created and managed only after specific events occur.

Structuring CMMN Sub-Case Relationships

Creating a subcase in CMMN means defining it as a child of the parent case. In visual modeling tools like Visual Paradigm, this is done through a dedicated Sub-Case element, attached to the parent case plan.

Here’s how it works in practice:

1. Define the parent case—e.g., “Insurance Claim Review.”
2. Identify distinct subcases—e.g., “Medical Evidence Evaluation,” “Fraud Detection Review,” and “Settlement Negotiation.”
3. Link each subcase using the Child Case dependency in the case plan model.
4. Set activation conditions using sentries (e.g., “When medical report is submitted”).
5. Define data sharing through shared case file items.

Each subcase can have its own stages, tasks, and milestones. But they are all governed by the parent case’s lifecycle and rules.

Key Data Flow Patterns in Nested CMMN

Data must flow between parent and child cases. The most effective way? Use case file items that are accessible across levels.

For example:

• Parent case stores: Claim ID, Claimant Name, Claim Date.
• Subcase “Fraud Detection” needs Claim Amount, Claim Date, and History of Past Claims.
• These items are shared via case file references—no duplication, no drift.

Use the Shared Data attribute in the case file to mark items that should be available to child cases. This avoids redundant data entry and ensures consistency.

Managing CMMN Dependencies and Activation

One of the most common challenges in nested models is controlling CMMN dependencies. A child case shouldn’t activate prematurely. It shouldn’t block the parent either.

Activation is governed by sentries—either event-based or condition-based. Here’s how to manage it:

Activation Strategies for CMMN Subcases

Choose one of these to control when a subcase becomes active:

1. Event-Driven Activation: The subcase starts when a specific event occurs—e.g., “When the medical report is uploaded.”
2. Condition-Based Activation: The subcase activates when a business rule evaluates to true—e.g., “If claim amount > $50,000, then activate fraud review.”
3. Manual Activation: A user explicitly triggers the subcase via a button or action. Useful for discretionary workflows.

Use Entry Criteria on the subcase to define when it’s eligible. But remember: eligibility ≠ activation. The user (or system) must still explicitly start it—unless you use a Direct Activation rule.

Here’s a practical example:

Subcase	Activation Trigger	Dependency Type
Fraud Detection	Claim amount > $100,000	Conditional
Medical Review	Medical report received	Event-driven
Settlement Negotiation	Approved by legal team	Dependency on parent task

Each of these defines a different kind of CMMN dependencies. The key is to choose the right one based on business needs, not just technical convenience.

Best Practices for Nested CMMN Modeling

Modeling nested cases is powerful—but easy to overcomplicate. Here are the rules I’ve learned from years of working with teams:

• Keep subcases focused: Each should handle one core business function. Avoid merging unrelated workflows into one subcase.
• Use clear naming conventions: e.g., “Claim_Review_Fraud_Detection” helps distinguish roles and purpose.
• Minimize cross-case data duplication: Share only what’s necessary. Use references, not copies.
• Document activation logic: Don’t assume users know why a subcase appears. Add comments or annotations.
• Validate with real users: Run simulations with case managers. See where the model breaks—especially in dependency logic.

One team I worked with once created seven subcases under a single parent. It looked impressive—but the model failed in testing. Why? Because activation rules were too complex, and no one could track which subcase was responsible for what. I simplified it to three core subcases with clear triggers. The performance improved, and user satisfaction rose.

Common Pitfalls and How to Avoid Them

Even experienced modelers fall into traps with nested CMMN. Here are the top three:

1. Over-reliance on automatic activation: Just because a condition is met doesn’t mean the subcase should start. Always ask: “Who makes this decision?”
2. Ignoring data ownership: If the parent case owns a data item, don’t let a subcase modify it without authorization. Add a Read/Write Rule in the case file.
3. Missing lifecycle coordination: A subcase might finish, but the parent stays open. Define exit criteria or auto-closure rules.

Always ask: “Can this subcase be managed independently?” If yes, it might be better as a standalone case. If no—it belongs nested.

Frequently Asked Questions

What’s the difference between a CMMN subcase and a BPMN subprocess?

A CMMN subcase is a full case in its own right—complete with stages, tasks, and data. A BPMN subprocess is a sub-flow within a process. Subcases are autonomous by design; subprocesses are part of a larger flow.

Can CMMN dependencies exist across multiple levels?

Yes. Subcases can depend on other subcases, or on tasks within the parent. Use sentries and case file items to model cross-level dependencies. Just keep the logic transparent.

How do I prevent a subcase from triggering prematurely?

Set a clear entry criterion using a condition or event. Don’t rely on default activation. Use a manual trigger unless the business rule is unambiguous and safe.

Are nested CMMN models harder to test?

They are more complex, yes. But with proper activation rules and data sharing, they are no harder to simulate than flat models. Use visual simulation tools to walk through scenarios.

Can I reuse the same subcase in multiple parent cases?

Yes—by making it a Reusable Subcase element. Just ensure the data model and rules are generic enough to apply across contexts. Be cautious with task-specific dependencies.

What’s the impact of nesting on performance in a case management system?

Nesting adds overhead in terms of data coordination and state tracking. But it’s usually negligible in modern systems. The real cost is in model complexity and maintenance. Balance depth with clarity.