invalidFlowRef

Sequence flow sourceRef / targetRef must resolve to an existing node.

Why it matters

A `<sequenceFlow>` whose `sourceRef` or `targetRef` points to a non-existent node is a dangling reference: the engine cannot wire the token route, so the flow is silently dropped on import (Camunda Modeler) or rejected with a generic "no such element" message (jBPM, Activiti). Either way, the diagram looks fine in the editor but behaves wrong at runtime — exactly the failure mode that escapes manual review.

What triggers it

For every `<sequenceFlow>` in the document, the validator resolves both `sourceRef` and `targetRef` against the doc-wide recursive node-id set (covering nested subprocesses, transactions, and ad-hoc subprocesses). When the id is unknown, the validator computes a Levenshtein-1 suggestion against the actual node ids — typically catching the "approve_v2" → "approve_v3" typo class.

How to fix

Read the error: it includes the bad id and, when one exists, a "did you mean X" hint. Either rename the target to match the existing node, or remove the orphaned flow. Modeling tools usually have a "delete flow" affordance that handles both ends — manual XML edits are the typical source of these errors, because deleting a node by hand does not clean up its references.

Examples

<process id="P">
  <startEvent id="s" />
  <task id="approve_v3" name="Approve" />
  <endEvent id="e" />
  <sequenceFlow id="f1" sourceRef="s" targetRef="approve_v2" />
  <sequenceFlow id="f2" sourceRef="approve_v3" targetRef="e" />
</process>

<process id="P">
  <startEvent id="s" />
  <task id="approve_v3" name="Approve" />
  <endEvent id="e" />
  <sequenceFlow id="f1" sourceRef="s" targetRef="approve_v3" />
  <sequenceFlow id="f2" sourceRef="approve_v3" targetRef="e" />
</process>