CMMN Case Models overview

CMMN (Case Management Model and Notation) is an OMG standard for modelling knowledge work — work where the goal is known but the path is not. Where a BPMN process prescribes a sequence, a CMMN case declares a set of things that may happen, each guarded by a condition, and lets the case worker decide what actually happens and in what order.

The canonical example is a claim, an investigation, or an onboarding: everyone agrees what “done” looks like, nobody can draw a single arrow-path through it in advance.

Case Management is not available in a released build

Feature::CaseManagement (key case_management) is built: false in the platform’s feature catalog, at min_tier: Tier::Business. On every shipped image the Case Models page renders the locked upgrade prompt, not the editor.

What exists today, and what does not, is set out precisely in What is actually built below. Read that section before planning any work against this page. Nothing on the rest of these pages is reachable through a released product yet.

CMMN in one diagram’s worth of words

A CMMN model has one outermost container, the case plan model. Inside it sit plan items — the things that can happen. Each plan item points at a plan item definition (a human task, a stage, a milestone, an event listener) and carries its own item control (is it required? does it repeat? must a human start it by hand?).

A plan item becomes available when the case starts, and then moves through a lifecycle of twelve states. What moves it is either a person, or a sentry: a guard attached to the plan item as an entry criterion (start watching for this) or an exit criterion (stop when this happens). A sentry watches other plan items’ lifecycle events — most often “this other task completed” — and may additionally carry an if-part, a boolean condition on case data.

That is the whole model. There are no sequence flows, no gateways, and no tokens. A connector on a CMMN canvas runs from a plan item to a criterion, never from plan item to plan item — the criterion is what a connector targets, and the sentry behind it decides whether the host becomes available.

CMMN versus BPMN — which one you want

	BPMN Flow	CMMN Case Model
Models	A prescribed sequence of activities	A set of permitted activities and their guards
Control flow	Sequence flows and gateways; a token moves	Sentries on lifecycle events; no token exists
The author decides	What happens next	What is allowed to happen, and when
The runtime decides	Everything — the path is in the diagram	Nothing; a person drives the case
Reach for it when	The process is the same every time	The goal is fixed and the route is not
Availability	Shipped, Business tier	Not shipped — see the box above

They are not competitors. A CMMN case task can call a BPMN process, and a BPMN process can be one step of a case — though neither call is executed by Orvanta’s engine yet (see Supported CMMN elements).

If you are choosing an authoring surface for work that does follow a fixed path, you want Choosing a flow authoring model instead — that page compares DAG Flow, BPMN Flow and Code Flow, all three of which ship today.

What is actually built

Orvanta is building CMMN in tracks. This is the state at platform commit cb4b0e66 (2026-08-10) and it is deliberately spelled out rather than summarised as “in progress”.

Merged and real

The model and validator (orvanta-cmmn). CMMN 1.1 XML parses into a typed model, and a deploy-time validator checks it. Measured against the 968 CMMN documents in the Flowable OSS repository: 967 of 967 acceptance documents parse, 889 carry no unsupported construct, 859 validate.

The case engine (orvanta-cmmn, same crate). A pure, I/O-free implementation of the plan-item lifecycle, sentries, item-control rules, repetition and completion. It has no database, no clock and no network by construction.

The editor. A CMMN 1.1 canvas with its own Case Models sidebar entry, reached at /case-models. It round-trips all 968 corpus documents byte-identically — a file you import and export unchanged comes back out unchanged, including constructs the editor cannot draw.

The server-side deploy and run path. cmmn_case_model / cmmn_case_model_version tables, a case-model API (orvanta-api-cmmn) whose create and update both call orvanta_cmmn::admit and refuse a model by name rather than deploying it, JobKind::CmmnCase, and worker_cmmn driving the engine. Instance control — start, get, suspend, resume, terminate, close — exists as routes.

Merged, but not what it looks like

The editor is not wired to any of that. It saves to localStorage and to a .cmmn file, and its only save control is Save draft; there is no Deploy button. The Case Models page lists local drafts, which the page itself says in an alert. So the deploy path exists and the authoring surface cannot reach it — which is why nothing here is usable end to end yet. Use Export to get a .cmmn file out of the browser; clearing site data loses anything you have not exported.

Not built at all

Capability	State
Deploying a case model from the editor	The server route exists; the editor is not wired to it
The case view (stage overview, open tasks, audit trail)	Not built. The stage-overview derivation exists in orvanta-cmmn as a pure function; there is no surface that renders it
Case migration between definition versions	Not implemented, and not started — see Coming from Flowable
An in-product test framework for case models	Does not exist
CLI and git-sync support for .cmmn	The cmmn_case kind is registered, deliberately ahead of the sync arm; a cmmn_case payload is reported as an unsupported kind rather than silently dropped

Reaching the editor in local development

ORVANTA_BETA=true reveals not-yet-built surfaces in a local build. It satisfies the built dimension only — it deliberately does not bypass entitlement, so the workspace must also sit at Business tier or above (locally, ORVANTA_DEV_TIER). Released images leave ORVANTA_BETA unset, and no licence can switch on a feature whose code is not there.

How to read the rest of this section

The five fundamentals pages teach the CMMN model itself, written against Orvanta’s engine rather than against the specification:

1. Stages, plan fragments and milestones — the containers.
2. Tasks and plan items — the work, and the twelve-state lifecycle.
3. Sentries — the guards. The page most likely to prevent a real bug.
4. Repetition — doing a thing more than once.
5. Stage and case completion — when a case is finished.

Then the reference and concept pages:

• Supported CMMN elements — exactly what the engine executes and what it refuses.
• Authoring a case model — the editor.
• Case data — case variables, and why Flowable’s “Data Objects” page is a false friend.
• Asynchronous execution — what flowable:async means, and why it is refused.
• Coming from Flowable — case view, migration, testing: the honest gaps.

A note on “CMMN 1.1 conformance”

Orvanta does not implement CMMN’s Case File model — caseFile, caseFileItem, caseFileItemDefinition, caseFileItemOnPart, caseFileItemStartTrigger. This is a deliberate exclusion on evidence, not an oversight, and it is stated here so that “CMMN 1.1” is not left to imply it. See Case data for the reasoning and for what Orvanta uses instead.