Case Management User Manual
A practical guide to modeling, deploying, and running Case work for situations where the path to completion depends on evidence and judgment rather than a fixed sequence.
Introduction
A Case Definition describes a unit of adaptive, knowledge-intensive work. Unlike a strictly ordered workflow, a case does not force every piece of work down one predetermined path. It is built from plan items, including Human Task, Decision Task, Stage, and Milestone, that become available or start automatically once the conditions around them are satisfied. This makes CMMN a good fit for work like loan review, exception handling, or investigation, where a case worker's judgment genuinely changes what happens next.
This manual walks through the building blocks of a case, how a Case Instance behaves once it is running, and how Human Tasks, Sentries, and Milestones fit together to move a case toward completion.
When to choose CMMN over BPMN
Use a BPMN process when the steps and their order are known in advance. Reach for CMMN when the exact path depends on incoming evidence, external events, or a case worker deciding what to do next. The table below maps the closest equivalent concept in each notation.
| BPMN concept | Closest CMMN concept |
|---|---|
| Process Instance | Case Instance |
| Sequence Flow | Entry / exit criteria and Sentries |
| User Task | Human Task plan item |
| Subprocess | Stage |
| End Event | Case-plan completion |
| Progress marker | Milestone |
Case Definition
A Case Definition is the authored, deployable blueprint for a case: the plan items it contains, how they relate to one another, and which forms and decision tables they call. It is created in the CMMN modeler and given a stable key, such as library-borrowing-case, that identifies it across versions.
The Case Plan Model
Every Case Definition has exactly one top-level Case Plan Model. It is the container that owns the case and everything inside it. Enabling Auto-complete stage on the Case Plan Model tells the runtime to close the case automatically once every required plan item has reached a terminal state; otherwise the case waits for an explicit completion signal.
Stages
A Stage groups related plan items into a phase of work, such as Evidence collection or Final review. Stages can be nested, can carry their own entry and exit criteria, and, like the Case Plan Model, can be set to auto-complete once their required contents finish. Grouping work into Stages keeps a large case plan readable and lets you attach criteria to a whole phase rather than to each item individually.
Case Instance
Starting a Case Definition creates a Case Instance, a single running occurrence of the case with its own data, its own plan item states, and its own history. A case starts with an empty set of case variables; the first Human Task's form is typically what populates them.
Case variables
Every value submitted through a Human Task's form, and every output produced by a Decision Task, is merged into the case's variables. Later Decision Tasks and Sentry conditions read from this same pool, so a field key such as credit_score must match exactly wherever it is referenced.
Instance lifecycle
A Case Instance moves between a small set of states: active, completed, or terminated. An authorized user can Suspend, Activate, Complete, or Terminate a running case from the Operations view, but Complete should only be used once outstanding required work is actually finished, not as a shortcut past it.
Human Tasks
A Human Task represents work performed by a person rather than the system. It can optionally link a published form, which collects the data the case needs to continue. At runtime, a created Human Task is claimed and completed from the Human Task queue.
Blocking vs. discretionary
Marking a Human Task as a Blocking human task means the case must wait for it to finish before continuing. A discretionary item, by contrast, is optional work a case worker can choose to start; it appears under Plan and event items and is started with Activate only when it is genuinely needed, such as investigating a flagged exception.
Claiming and completing
A case worker selects Claim to take ownership of an available task, then Complete once the work, including any linked form, is finished. Completing a Human Task updates case variables, records an entry in the case's history, and re-evaluates every Sentry that depends on it.
Sentries
A Sentry is the condition that controls when a plan item starts or completes. It combines an event, such as another plan item completing, with an optional Boolean expression, and only fires once both are true. Sentries are what let a case plan branch and react instead of following one fixed sequence.
Entry criteria
An entry criterion controls when a plan item becomes available to start. The most common pattern chains a Human Task to a Decision Task, and the Decision Task to a Milestone:
Library borrowing plan [auto-complete]
|- Collect borrowing evidence [blocking Human Task + Form]
|- Assess borrowing request [Decision Task + DMN]
|- Borrowing outcome recorded [Milestone]
`- Investigate member exception [optional / discretionary Human Task]
Collect borrowing evidence completes
-> entry sentry starts Assess borrowing request
Assess borrowing request completes
-> entry sentry achieves Borrowing outcome recordedExit criteria
An exit criterion ends a plan item, or an entire Stage, early, even if its own work is unfinished. This is useful when one outcome makes the rest of a phase unnecessary, for example cancelling a review Stage once a Decision Task already declines the case. Conditions that go beyond what the visual inspector exposes, such as a Sentry combining several source events, can be authored as raw CMMN XML and imported into the model:
<cmmn:sentry id="Sentry_AssessRequest">
<cmmn:planItemOnPart sourceRef="PI_CollectEvidence">
<cmmn:standardEvent>complete</cmmn:standardEvent>
</cmmn:planItemOnPart>
<cmmn:ifPart>
<cmmn:condition>
<![CDATA[ member_active == true ]]>
</cmmn:condition>
</cmmn:ifPart>
</cmmn:sentry>Milestones
A Milestone records a meaningful business achievement, such as Eligibility determined or Stock registered. A Milestone has no work form of its own; it exists purely to mark progress, and a case is often considered functionally complete once its key milestones are reached.
Achieving a milestone
Most Milestones are achieved automatically once their Sentry becomes true, typically right after the Decision Task or Human Task that determines the outcome finishes. Where no automatic Sentry applies, a permitted user can select Achieve from the Milestones queue once it becomes available.
Process User Manual
A practical guide to modeling, deploying, and running Process definitions for work that follows a predictable, repeatable sequence from start to finish.
Introduction
BPMN describes work as a Process Model: a diagram of connected activities, gateways, and events that shows exactly how work is meant to flow. Where CMMN suits adaptive, judgment-driven work, BPMN is the right tool when the sequence of steps is known ahead of time and every route through the diagram can be drawn out in advance.
This manual covers the pieces that make up a process: the Process Definition itself, the Activity types available, how a Gateway routes work conditionally, and the Event types that start, pause, or end it.
Key concepts
Every executable process needs a Start Event, a connected path of activities, and at least one End Event. Every route leaving a gateway should carry either a condition expression or be marked as the gateway's default route, so the runtime always has somewhere to go regardless of the data it receives.
Process Model
The Process Model is the diagram you build in the BPMN modeler: Start Events, activities, gateways, sequence flows, and End Events laid out on a canvas. Selecting the process or participant and confirming Executable process in the element properties panel is what makes the model something the runtime can actually execute, rather than a purely descriptive diagram.
Pools and lanes
Larger diagrams often use a pool to represent the whole process and lanes inside it to show which role or team is responsible for each activity, such as a Warehouse lane and an Inventory Supervisor lane. Lanes don't change how the process executes; they exist to make responsibility visible on the diagram itself.
Process Definition
A Process Definition is the deployed, immutable version of a Process Model, identified by a stable key such as loan-application-process. It is what the runtime actually starts when a user selects an entry point from Work.
Versioning a definition
Editing and redeploying a Process Definition creates a new version alongside the old one; it never rewrites history in place. Existing running instances keep executing against the version they started on, while new instances pick up the latest deployed version. This is what makes it safe to improve a process without disrupting work that's already underway.
Activities
An Activity is a unit of work inside the process. A User Task is claimed and completed by a person, typically backed by a linked form. A Business Rule Task evaluates a deployed DMN decision table instead, using its result to drive the process forward without any manual step.
Task types
A User Task can be assigned directly to one person, offered to a list of candidate users, or offered to everyone in a candidate group, in which case any member can claim it. A Business Rule Task's output is merged directly into process variables when no result variable is set; a decision output named eligibility becomes the process variable eligibility automatically.
Gateways
A Gateway is where the process decides which path to take next based on the data collected so far. Every outgoing sequence flow from a gateway needs a condition expression, unless it has been marked as the default route for unmatched cases.
Exclusive gateways
An Exclusive Gateway takes exactly one outgoing route: the first one whose condition evaluates to true. A typical condition compares a process variable produced by a Business Rule Task:
${eligibility == "approved"}Configuring one route as the gateway's default ensures the process still has somewhere to go if none of the explicit conditions match, for example by routing a borderline credit score to manual review rather than leaving the instance stuck.
Parallel gateways
A Parallel Gateway splits execution into several simultaneous branches, which is useful when, say, a compliance check and an inventory check can happen at the same time. A matching Parallel Gateway later merges the branches back together once all of them complete.
Events
An Event marks something that happens to the process: it starting, ending, or pausing to wait for something external.
Start and end events
Every executable process needs exactly one triggering Start Event and at least one End Event. Diagrams that model alternative outcomes, including approved, declined, or sent for manual review, often use several End Events, one for each way the process can conclude, so the outcome is visible directly on the diagram.
Intermediate events
Between the start and the end, an Intermediate Event can pause a running instance until a timer elapses or an external message arrives, for instance while waiting for a supplier's confirmation before an inventory receipt process can continue. While a process instance is parked at one of these events, its status in Operations shows exactly what it is waiting for.
Put together, a complete loan-application process reads intake through a gateway that routes on the outcome of an automated eligibility check:
Application received
-> Capture loan application [User Task + Form]
-> Evaluate loan eligibility [Business Rule Task + DMN]
-> Eligibility outcome [Exclusive Gateway]
approved -> Approve eligible application [User Task]
review -> Manually review application [User Task, default route]
declined -> Record declined application [User Task]
-> Application completed [End Event]