Coming from Flowable

If you are evaluating Orvanta’s CMMN support against Flowable’s, these are the three areas where the difference is largest and least visible from a feature list. Each is stated plainly rather than omitted, because an omission reads as an oversight and this is not one.

The short version

Orvanta today has a CMMN model, a validator, an execution engine, an editor, and a server-side deploy and run path. It has no case view, no case migration, and no in-product test framework. The editor is also not yet wired to the deploy path, so none of this is reachable end to end from the product.

The case view

In Flowable, a running case gets a case view: a left-hand navigation over the live case instance, typically carrying a stage overview, the open tasks, a form for the task in hand, an audit trail, and any case pages the model declared.

Orvanta has no case view. There is no surface that displays a running case, because there is no running case.

Some detail on the pieces, since they are not equally far away:

Piece	State in Orvanta
Stage overview	The nearest to existing. flowable:includeInStageOverview (311 corpus files) and flowable:displayOrder (62) are parsed and round-trip, and the engine crate derives the ordered overview from a compiled model as a pure function. There is still nothing to render it in.
Open tasks	Blocked on a task store, not on the engine.
Audit trail	The engine emits a trace of lifecycle events per pass; no surface displays it.
Work form	The nearest thing that exists is the form surface built for BPMN user tasks, not for CMMN.
Comments, chat, people, documents	No backing store exists at all. These are not “not wired up” — there is nothing behind them.
Case pages (<casePageTask>)	Refused by the parser. Zero corpus occurrences as an element name.

That last row is worth a note for anyone porting: a case page activates with its parent and can never complete. If you have modelled one expecting it to gate anything, it does not.

Case migration

Flowable can migrate a running case instance from one version of a case definition to another. Its migration document lets you name a target definition (toCaseDefinitionKey plus a version), terminate plan item definitions, move plan item definitions back to available, and activate, add-repetition or remove-repetition on specific items — each operation optionally guarded by its own condition expression.

Orvanta does not implement case migration. Not partially, not in a limited form — there is no migration document, no migration API and no migration code. This is stated on its own page section rather than left out, because an evaluator comparing against Flowable will look for it and finding nothing is ambiguous where a plain “no” is not.

What this means practically, once cases do run: deploying a new version of a case definition will not move instances already in flight. Plan for in-flight cases to finish on the definition version they started on, and for any change of shape to need a drain-and-cut-over rather than a migration.

Testing case models

Flowable ships an in-product test framework for case models — ordered test steps bound to plan items, actions to drive them, assertions on the resulting state, and pin annotations shown on the diagram.

Orvanta has no equivalent. There is no in-product test framework for case models, and no plan on this page’s authority for one.

What exists instead is engine-level, and it is not a substitute for authoring-time testing:

• A conformance corpus. All 968 CMMN documents from the Flowable OSS repository are in-tree as fixtures, scored at five tiers against a committed baseline that fails on regression. See the scorecard.
• A round-trip test asserting byte-identical save-open over the same 968 documents.
• Generated support tables that fail their own test if the code and the published table disagree.
• A trace oracle. Construct-dense fixtures are replayed against event traces recorded from a real flowable-cmmn-engine 7.2.0 and scored against a committed baseline. This is the only thing that compares Orvanta’s execution against Flowable’s, and it covers five fixtures, not the corpus — see the scorecard for where it stands.

Those tell you the engine did not regress. They tell you nothing about whether your case model is correct, and the T3 caveat applies: T3 means “ran to a stable state without hanging”, over 967 documents, and must never be added to or quoted alongside the five-fixture oracle result.

Until an authoring-time test surface exists, the practical loop is: model it in the editor, export the .cmmn, and reason about the sentries by hand — with Fundamentals 3 open, because trigger modes are where models go wrong silently.

What to check before planning a port

A short list, in the order that will save you the most time:

1. Does the model use processTask, caseTask, decisionTask or timerEventListener? All four are refused. Between them they block 146 of the 967 corpus documents.
2. Do the sentry if-parts fit the decidable subset? This is the single largest blocker at 107 documents. Any method call, arithmetic, indexing or ternary refuses.
3. Does it use the generic <eventListener>? 78 documents do, and it is refused at parse.
4. Does it use flowable:async? 33 documents do. Removing it is usually free.
5. Does it use a computed collection variable, or an aggregator Orvanta refuses? Plain collection-based repetition and variableAggregation now execute; the exceptions are listed there.
6. Does it rely on running instances surviving a definition change? There is no migration.

Everything on that list refuses at deploy, by name, rather than deploying and misbehaving, and deploy is where the check happens: creating or updating a case model runs the admission check and rejects the model rather than storing it.

See also

• CMMN Case Models overview — the full build-state table.
• Supported CMMN elements — every refusal and the conformance scorecard.
• Importing from Flowable/Camunda — the equivalent page for BPMN, which does ship.