Case data

CMMN’s specification defines an elaborate data model — the Case File — that almost nobody uses. This page explains what Orvanta uses instead, and disambiguates two pieces of Flowable documentation that mislead in opposite directions.

Note

Nothing on this page is reachable through a released Orvanta build — see the overview’s status section.

Named case variables

Orvanta’s case data model is named case variables: a flat, JSON-valued map on the case instance.

A case is started with a set of start variables, exactly as Flowable’s startCaseInstanceByKey(key, variables) does. Everything that reads case data — a sentry if-part, a requiredRule condition, a manualActivationRule condition, a repetitionRule condition, an autoCompleteCondition — resolves names out of that map.

Dotted paths work: ${order.total} walks into a nested JSON object.

Local variables shadow case variables

A plan item instance may carry local variables. Today the only one the engine creates is the repetition counter, under whatever name flowable:counterVariable gives it.

When a condition is evaluated for a plan item, the engine resolves names against the case variables overlaid with that instance’s local variables — so a local variable shadows a case variable of the same name. This matches Flowable’s resolution order.

Truthiness

Worth repeating here because it is a data question as much as a condition question: a non-boolean expression result evaluates to false, following Flowable rather than JavaScript. ${someString} is false however non-empty the string is. Write ${not empty someString} if you mean “is set”.

The Case File model is out of scope

CMMN 1.1 defines <caseFile>, <caseFileItem>, <caseFileItemDefinition>, <caseFileItemOnPart> and <caseFileItemStartTrigger> — a typed, hierarchical document model with its own lifecycle and its own sentry on-part flavour.

Orvanta does not implement any of it, deliberately.

The evidence is one number:

caseFileItem appears in 0 of the 968 CMMN documents in the Flowable OSS repository.

Not “rarely”. Zero. Flowable does not implement CMMN’s Case File model at all — its data model is named case variables, which is why Orvanta’s is too. Building the Case File subsystem would be conformance theatre against a construct no Flowable user writes.

So the parser names these constructs and refuses them rather than pretending, and caseFileItemOnPart is refused at the sentry level too. <children> and <property> — both Case File children — are consequently unreachable and ignored.

This is stated plainly because “CMMN 1.1” must not be left to imply Case File support. An evaluator comparing Orvanta against the specification will look for it; the answer is that it is excluded on evidence, and that Flowable’s exclusion is the same.

Two false friends in Flowable’s documentation

If you are reading Flowable’s docs alongside these pages, two things there will mislead you.

”Data Objects” is not dataObject

Flowable’s “Data Objects” documentation page does not document CMMN’s <dataObject> or <caseFileItem>. It documents a proprietary, externally-stored typed-entity feature — data object models, a Lookup ID, a Liquibase “Generate schema” button, and Create/Lookup/Update/Delete/Search tasks against a separate store.

That is a Flowable product feature, not a CMMN construct. Orvanta has no equivalent concept and is not planning one under this name. Reading that page and expecting it to describe case data will send you looking for something that was never part of the standard.

The reactmodel pages are not a specification

Flowable’s reactmodel CMMN documentation contains zero CMMN XML element or attribute names — every concept is named by its modeller property label (“Impact on parent completion”, not parentCompletionRule). It cites the OMG CMMN 1.0 specification for the lifecycle, never claims 1.1 conformance, and never discusses XML import, export or round-tripping.

It is useful for understanding intent and useless for implementation. Orvanta’s model was built against the OMG CMMN 1.1 schemas and Flowable’s own engine source instead — which is why these pages name XML elements throughout.

What case data cannot do yet

Write a variable from a task	Nothing in a CMMN case runs user code yet — every task is a park-and-wait or a pass-through
Aggregate variables across repetitions	flowable:variableAggregation is refused
Iterate a collection	Collection-based repetition is refused
Map data in and out of a called process or case	<input>, <output> and <parameterMapping> are not modelled; processTask and caseTask are refused anyway

On that last row: flowable:in and flowable:out (39 and 26 corpus occurrences) are captured in the extension-element tree and survive a round trip — they are Flowable’s actual data-flow mechanism, where the spec’s <parameterMapping> is the unused one.

See also

• Fundamentals 3: sentries — where case data is actually read.
• Supported CMMN elements — the full out-of-scope list.