duplicateId

All id attributes must be unique across the document.

Why it matters

BPMN 2.0 declares every `id` attribute as a globally unique identifier across the entire document, not just within a single process or scope. Engines (Camunda, Flowable, Zeebe, jBPM) use the id as the primary key when persisting process instances, hydrating tokens after restart, and routing events. A duplicate id means the engine cannot tell two activities apart — runtime symptoms range from "import rejected" stack traces with no actionable detail to silent token loss where a message lands on the wrong activity. Our validator surfaces every collision with its line number so the fix is mechanical.

What triggers it

The validator counts every `id` attribute across the document and flags any value that appears more than once. The check runs across all namespaces (BPMN semantic + BPMN DI) and across every nesting level — a duplicate between a top-level `<task>` and a `<bpmndi:BPMNShape>` is just as fatal as two tasks sharing an id.

How to fix

Rename one of the colliding elements to a fresh, unique id. Conventional naming patterns help: prefix tasks with `task_`, gateways with `gw_`, events with `evt_`. Modeling tools (Camunda Modeler, bpmn.io, Lucidflow) auto-generate ids on insert, so the most common source of duplicates is copy-paste from another file — always re-id pasted nodes. If the duplicate is between semantic and DI elements (e.g. a `<task id="t1">` and a `<BPMNShape id="t1">`), only the semantic id needs to be unique on its own; the DI id can be `<task-id>_di` by convention.

Examples

<process id="P">
  <task id="approve" name="First approval" />
  <task id="approve" name="Second approval" />
</process>

<process id="P">
  <task id="approve_1" name="First approval" />
  <task id="approve_2" name="Second approval" />
</process>