Modeling Case File Items and Data Dependencies

Estimated reading: 7 minutes 7 views

Many modelers start with a simple assumption: a case file is just a container for data. But that’s where the first misunderstanding begins.

Look at the typical CMMN diagram you find online: a case plan with a few labeled tasks and a “Data” section in the corner. It looks clean. It’s tidy. It’s misleading.

That model assumes data flows are static, predictable, and reusable across cases. In reality, every case — especially in healthcare, insurance, or legal services — evolves differently. The same document type may need different fields depending on context. The same task may require different inputs based on prior decisions.

That’s why the real work isn’t in drawing boxes. It’s in modeling how data changes form, when it’s created, and how tasks depend on its state. This is where CMMN case file modeling becomes both science and art.

My 20 years of experience with enterprise case modeling have taught me this: a well-designed case file isn’t just a list of variables. It’s a living, breathing system that evolves as the case progresses. If you don’t get the data dependencies right, your model may look correct — but it’ll fail in real execution.

Here, you’ll learn how to model dynamic data with precision — not just in theory, but through real modeling decisions, trade-offs, and practical patterns.

Understanding CMMN Case Files and Their Role

The CMMN Case Plan Model defines a case as a flexible, goal-driven structure. At its core is the CMMN case file — a logical container that manages all data relevant to a case.

It’s not just for storing data. It’s about managing state, dependencies, and access control. When a task is activated, it doesn’t just need data — it needs the right data, in the right state, at the right time.

Consider a medical intake case: the case file holds patient history, lab results, and doctor notes. But the same file must also track whether consent forms are signed, whether a specialist has reviewed records, and whether a referral has been approved.

Each of these is a case file item. The key is not just naming them, but defining how they’re used, modified, and referenced across tasks.

What’s in a Case File?

Case file items are not arbitrary. They must be explicitly defined in the model and linked to tasks through data dependencies.

Here’s what a real CMMN case file should contain:

Input data – data passed into the case from external systems or user input.
Output data – data generated by tasks, such as a completed risk assessment or a final decision.
Intermediate data – variables that evolve over time, such as status flags, timestamps, or review comments.
Document references – pointers to external files (PDFs, scanned images, databases) that are part of the case.

Each item should have:

A unique identifier
A data type (e.g., string, date, boolean)
An optional default value
A scope (e.g., case-level, task-level)

These aren’t placeholders. They’re part of the case’s logic.

Modeling Case File Items with Precision

Most tools let you add data to a case file with a few clicks. But that’s not modeling — it’s data entry.

Real CMMN data modeling begins with clarity: what does this item represent? Who owns it? When can it change?

Ask yourself:

Is this data created during a task, or is it provided from the outside?
Can multiple tasks modify it simultaneously?
Does it affect task activation conditions?

These questions shape how you define and reference the item.

Three Key Modeling Patterns for Case File Items

Over time, I’ve seen three patterns emerge that consistently deliver robust, maintainable case files.

1. Task-Driven Item Creation

Some data is generated only after a task is completed. For example, a “Medical Review” task generates a “Summary Report” item.

Model this by:

Defining the item as an output of the task.
Setting the task’s exit condition to “Report is created”.
Ensuring the item is not available until the task finishes.

This pattern avoids premature data access and ensures consistency.

2. Shared State Items

Some items are shared across tasks — like a “Case Status” field that changes from “Open” to “Under Review” to “Closed”.

Model this with:

A single case file item with a state machine (e.g., Open → Review → Approved/Rejected).
Tasks that modify the state as a side effect.
Sentries that activate tasks based on state changes.

Example: When “Case Status” becomes “Under Review”, the “Assign Specialist” task becomes eligible.

3. Document-Backed Items

Some data isn’t stored in the model — it’s a reference to a file. A scanned consent form, an MRI report, a signed contract.

Model this by:

Creating a case file item of type “File Reference”.
Linking it to a document repository (e.g., SharePoint, document management system).
Setting access rules: only specific roles can view or modify it.

When a task requires this file, use a sentry condition like: “Document exists and is approved”.

Mapping Data Dependencies: The Hidden Logic

Tasks don’t just depend on data. They depend on the state of data.

Consider a loan application case. The “Credit Check” task should not activate until the “Applicant Form” is complete and validated. The “Underwriting Review” task only runs if the credit score is above 650.

This is where CMMN data modeling becomes more than just labeling items.

You must define:

Which data items are required for task activation?
Which items trigger a task’s exit?
Are there conditional dependencies based on values?

For example:

Task	Required Data	Activation Condition
Medical Review	Lab Results, Consent Form	Both documents exist and are signed.
Insurance Approval	Credit Score, Risk Category	Credit Score > 650 AND Risk Category = “Low”

These aren’t just rules — they’re part of the case’s decision logic.

Use CMMN sentries to express these conditions. Never rely on text annotations. The model must be self-contained.

Best Practices for CMMN Data Modeling

Here are the patterns I’ve used in dozens of client projects to ensure data integrity and model clarity:

Define data items early – Don’t wait until the model is complete. Define all case file items in the initial design phase.
Use consistent naming – Prefer “Applicant_Name” over “name_1” or “input1”.
Limit scope – Avoid global variables. If a value is only used in one task, make it a local variable.
Document dependencies – Use a dependency matrix to track which tasks depend on which items.
Validate with real data – Simulate cases with different data paths to check for missing dependencies.

These aren’t just suggestions. They’re what separate a model that works from one that fails under real conditions.

Frequently Asked Questions

What’s the difference between a CMMN case file and a process variable?

Process variables are transient — they exist only during a workflow execution. Case file items persist across the entire case lifecycle. They’re stored, versioned, and often shared among multiple tasks.

Can case file items be updated after a task completes?

Yes — but only if the task allows it. Some tasks may lock data, while others allow edits after completion. This depends on business rules and role permissions.

How do I model data that changes over time?

Use intermediate items with history tracking. For example, “Risk Rating” can be a sequence of values: “High” → “Medium” → “Low”. Track each change with a timestamp and user ID.

Are there tools that help with CMMN data modeling?

Yes — Visual Paradigm, Camunda Modeler, and ARIS support full CMMN case file definition. Use the data model tab to define items, types, and dependencies.

How do I ensure data consistency across tasks?

Use sentry conditions to prevent tasks from running until required data is present and valid. Use task outputs to propagate state changes.

Can I model dynamic data structures in CMMN?

Not directly. CMMN assumes fixed data schemas. For highly dynamic cases, use external data models and reference them via file references or external APIs.