Importing from Flowable/Camunda

Orvanta parses BPMN 2.0 XML from Flowable, Camunda, and Activiti as a single dialect — all three vendors use the same OMG standard with closely related extension namespaces, and Orvanta recognises flowable:, camunda:, and activiti: attributes interchangeably where they overlap.

Measured conformance

Against a corpus of 1,754 real-world Flowable process definitions, the current engine:

Parses 45.5% without hitting an unsupported construct.
Fully validates 31.1% — parses and passes deploy-time validation.

These numbers come from an automated test suite run against the actual parser and validator (backend/tests/fixtures/bpmn/flowable_corpus/BASELINE.json in orvanta-platform), not an estimate. Orvanta does not have broad BPMN 2.0 support today — treat these figures as the honest current baseline, not a target already met. No single construct dominates the gap: the largest individual blockers are event sub-processes and callActivity (each ~7.7% of the corpus on their own), followed by receiveTask, multi-instance sub-processes, and boundary timer events — see the element reference for the full list of what’s supported.

What executes

Anything on the supported-elements list executes exactly as documented there, regardless of whether it originated in Flowable, Camunda, or Orvanta’s own modeller. A businessRuleTask with an orvanta:decisionRef evaluates its linked DMN decision table inline — see Decision models. Flowable’s own dialect for the same idea, a serviceTask carrying flowable:type="dmn", evaluates identically, reading its decision reference from a <flowable:field> instead. If either references a <decisionService> rather than a plain decision, the import deploys with a warning and evaluates only the single decision the service names — see Decision Services and DRDs. A serviceTask carrying flowable:type="external-worker" (or the legacy "external" spelling) also executes, as a wait state — see the element reference for exactly what each does.

flowable:async, asyncLeave/asyncAfter, and exclusive carry over from an import and execute. These Flowable extension attributes are honoured as forced quiescence boundaries on whichever element carries them — see Execution semantics for exactly what each does and the one documented over-approximation (asyncBefore, a Camunda-only spelling, is accepted rather than ignored). They aren’t yet authorable from the Orvanta editor itself — see Authoring a BPMN diagram — but an element imported with them keeps them, and the boundary is enforced at runtime either way.

Condition expressions are evaluated as JavaScript, not JUEL. Flowable and Camunda XML conventionally write conditionExpression and other expressions in JUEL, which has different coercion rules than JavaScript (for example ${'1' == 1} is true under JUEL, false under JavaScript ===). An imported process with JUEL-flavoured expressions may need those expressions rewritten by hand before it behaves identically in Orvanta. A dedicated JUEL evaluator is planned but not shipped.

What’s preserved but not executed

Pools and lanes (laneSet/lane), documentation, textAnnotation, association, and the BPMN diagram interchange elements (BPMNDiagram/BPMNPlane/BPMNShape/BPMNEdge) are parsed but their subtrees are neither rejected nor modelled — the engine simply doesn’t build an execution concept for them. The XML you deploy is stored as-is, so these elements round-trip byte-for-byte in storage; there is no swimlane-based execution semantic, and pool/lane structure has no effect on how a process runs.

extensionElements content — Flowable/Camunda I/O mappings (flowable:in/out/field, camunda:inputOutput), listeners, and form properties — is parsed and captured from a namespace-aware allowlist, but not yet consumed by the execution engine. It’s stored on the compiled element for future use, not acted on today. In practice this means variable input/output mappings expressed the Flowable/Camunda way don’t yet take effect after import; use Orvanta’s own script bindings instead.

What blocks deploy

Any element that falls outside the supported list — callActivity, multiInstance markers, event sub-processes, non-interrupting or non-error boundary events, receiveTask/sendTask, adHocSubProcess, terminateEndEvent, complexGateway/eventBasedGateway, and signal/escalation events — fails deploy-time validation with an error naming the specific element. Deploy-time validation is authoritative: the engine never silently drops or partially executes a construct it can’t fully support. If your process uses any of these, it can be imported for viewing but can’t be deployed until the unsupported constructs are removed or replaced with equivalents Orvanta does execute.

The Java delegate boundary

A serviceTask with a Java delegate (flowable:class, delegateExpression, or the legacy activiti:class) parses today, but currently has no bound Orvanta script — it fails deploy-time validation as a missing script binding rather than running the delegate. This is, on the measured corpus, the single largest reason a process that parses still fails to validate.

That failure is expected, not a gap Orvanta intends to close by running your Java code: Flowable doesn’t ship your delegate either. A delegate class is your application code, resolved by your classloader at your deploy — the same is true for any equivalent Orvanta binding. “Orvanta runs what Flowable runs” is true modulo user-supplied delegate bodies, which is exactly the modulo Flowable itself has. A dedicated deploy-time binding flow — resolve each delegate against an Orvanta script once, per workspace, with a clear error until it’s bound — is planned but not yet shipped; today, bind the equivalent logic to the task by hand after import.