Choosing a flow authoring model

Orvanta has three ways to author a flow: DAG Flow, BPMN Flow, and Code Flow. They are different authoring surfaces over one execution engine, not three separate products — this page is for deciding which one to reach for, and being honest about what each one costs you.

At a glance

	DAG Flow	BPMN Flow	Code Flow
Artifact	OpenFlow YAML/JSON	BPMN 2.0 XML	A Python/TypeScript script with `@workflow`/`@task` decorators
Authored as	Node-based canvas	BPMN 2.0 canvas	Code
Maturity	Most mature, no coverage gaps against its own model	Executes a defined subset of BPMN 2.0 (see below)	Full language power, no visual canvas
Portability	Orvanta-specific	Standards-based (with caveats — see below)	Orvanta-specific
Tier	Included in every tier	Business and Enterprise (verify current requirement)	Included in every tier

DAG Flow

What it is. Orvanta’s original, node-based flow model: a directed acyclic graph of steps — scripts, branches, loops, approvals, error handlers — wired together on a canvas. It compiles to an OpenFlow YAML/JSON artifact. See Workflows and Flows as artifacts.

When to choose it. It’s the most mature of the three authoring models and has no coverage gaps against its own feature set — everything the DAG model supports, the engine executes. Choose it by default unless BPMN or Code Flow’s specific trade-offs matter to you.

What it costs you. The artifact format is Orvanta-specific — there’s no external standard behind it, so it isn’t portable to another orchestration engine.

BPMN Flow

What it is. Process modelling using BPMN 2.0 notation, the standard used by Camunda, Flowable, and Activiti. A business-rule task can call out to a DMN decision table. See BPMN Flow overview.

When to choose it. Your team already thinks in BPMN, the process needs standards-based notation for governance or stakeholder review, or you’re migrating an existing Camunda/Flowable estate.

What it costs you — specifically, not just “some limitations”. The engine executes a defined subset of BPMN 2.0, not the full spec: see the element reference for the exact list of 18 supported element kinds. Measured against a corpus of 1,754 real Flowable process definitions, the engine currently parses 45.5% and fully validates 31.1% — that is the honest current baseline, not “broad BPMN 2.0 support”. callActivity, multi-instance activities, event sub-processes, and most boundary event types beyond interrupting error are not yet supported and block deploy rather than degrading quietly. If you’re evaluating BPMN Flow against a specific process, check it against the element reference before assuming portability. See Importing from Flowable/Camunda for the full picture, including what’s preserved read-only and what blocks deploy.

Code Flow

What it is. Orchestration written directly as a Python or TypeScript function, using @workflow/@task decorators (or their TypeScript equivalents) instead of a visual graph. Each task dispatches as a separate, checkpointed job. See Code Flow.

When to choose it. The orchestration logic is easier to express as a program than as a graph — dynamic branching, loops with non-trivial exit conditions, or a variable number of tasks computed at runtime.

What it costs you. No canvas, and no visual run overlay in the sense DAG Flow and BPMN Flow have — you get a checkpointed timeline of task jobs, not a live graph animation. It gives you the full expressiveness of the language you write it in, but 2 of the 28 declared script languages (MongoDB and Dart) don’t have a working executor yet regardless of which flow model dispatches them — check Scripts for the current language list before assuming a specific language runs end to end.

What about CMMN case models?

A CMMN case model is not a fourth flow authoring model, and it is deliberately not a fourth column in the table above — it isn’t reachable from the Create flow modal at all. It has its own Case Models sidebar entry, its own artifact format (CMMN 1.1 XML), and its own engine.

The distinction is not organisational, it’s a different question. The three models above all answer “what happens, in what order?”. A CMMN case model answers “what is allowed to happen, and under what conditions?” — it declares a set of permitted activities each guarded by a sentry, and lets a person decide what actually happens. There is no sequence flow, no gateway and no token. That’s the right shape for knowledge work — a claim, an investigation, an onboarding — where the goal is fixed and the route isn’t.

It is not available in a released build. Feature::CaseManagement is built: false at Business tier: the editor and the CMMN 1.1 round trip are real, but case models save to browser local storage, and there is no deploy path and no runtime. See the overview’s status section for the precise build state before planning anything around it.

If the work you’re modelling does follow a fixed path, one of the three models above is what you want — start with DAG Flow.

What’s shared across all three

This is the part that doesn’t change based on which model you pick: one execution engine, the same permissions and RBAC model, the same audit trail, the same ability to call any Orvanta script as a step, and the same runs UI for watching and debugging execution. Choosing an authoring model is a choice about how you build a flow, not about which platform capabilities you get.

Can you migrate between them?

No — not automatically. There is no converter between the OpenFlow (DAG Flow), BPMN 2.0 XML (BPMN Flow), and Python/TypeScript (Code Flow) artifact formats. Moving a flow from one model to another today means rebuilding it in the target model by hand. If you’re choosing between models for a new flow, that’s a reason to decide deliberately up front rather than expecting to switch later at low cost.