BPMN with AI: Generating Valid BPMN 2.0 XML That Opens in Camunda and bpmn.io

BPMN 2.0 is an XML file with a published schema, which means a language model can write it and git can version it like any other diagram as code. Generate the semantic layer, the pools, lanes, tasks, gateways, and flows, then open the file in Camunda Modeler or bpmn.io and let the tool handle layout. That workflow produces real BPMN, not a flowchart wearing a costume.

There is a moment on most projects where a sequence diagram stops working. You are in a room with operations, compliance, and a product owner, explaining a process that crosses four departments and two systems, and the technical diagram that served the delivery team perfectly is doing nothing for this audience. They need to see who does what, where the handoffs are, and what happens when the deadline passes.

That is BPMN’s job. It is the ISO standard for business process models, it has been the common language between business and IT for over a decade, and critically for this article it is stored as XML. Which puts it squarely inside the diagrams as code with AI workflow, even though nobody thinks of BPMN that way. If you want the deliverable templates that sit around a process model, they are in Real-World BA Deliverables.

When is BPMN the right choice, and when is it not?

Three conditions. If none of them hold, use a Mermaid sequence diagram or flowchart and save yourself the XML.

1. The audience is business. Swimlanes answer “who is accountable for this step,” which is the first question a business stakeholder asks and the one a sequence diagram answers worst.
2. The process crosses organisational boundaries. Pools and message flows make the handoff between your company and a partner explicit, including the fact that you cannot see inside their pool.
3. A process engine will execute it. Camunda, Flowable, and Zeebe consume BPMN 2.0 directly. If the model is going to run, it has to be real BPMN and nothing else will do.

The distinction from a sequence diagram is not cosmetic. A sequence diagram answers “which service called which, in what order, with what status code.” A BPMN model answers “who is responsible for this activity, what decides the branch, and what happens when the timer fires.” I have shipped projects that needed both, generated from the same source description, because the delivery team and the steering committee were genuinely asking different questions. That pairing is the same two-audience move described in sequence diagrams for business analysts.

The twelve elements that cover real process models

The BPMN 2.0 specification runs to several hundred pages. You need about twelve elements, and a business audience will never ask about the rest.

Element	What it means	When you need it
Pool	An independent participant, your organisation or a partner	Any cross-organisation process
Lane	A role or system inside a pool	Whenever accountability matters
Start event	What triggers the process	Always
End event	How the process terminates	Always, and usually more than one
User task	A human does the work	Manual review, approval
Service task	A system does the work	Automated validation, API call
Exclusive gateway	Exactly one path is taken	Any either-or decision
Parallel gateway	All paths run concurrently	Screening and enrichment at once
Sequence flow	The ordered arrow inside a pool	Always
Message flow	A message between pools	Cross-organisation handoff
Timer boundary event	A deadline on an activity	Any SLA or cutoff
Error boundary event	A failure path off an activity	Any step that can fail

The last two are the ones analysts skip and should not. A model without boundary events shows only what happens when everything works, which is the same failure as a happy-path-only sequence diagram: every unspecified exception is a missing requirement that surfaces during user acceptance testing at the worst possible time.

Generating the XML

The workflow that works is two layers, generated separately. The semantics first, the layout second, and never both at once.

Here is the semantic layer for a payment approval process, which is what you ask the model to produce:

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions
    xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
    xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
    targetNamespace="http://analystengineering.com/bpmn">

  <bpmn:process id="PaymentApproval" isExecutable="false">
    <bpmn:laneSet>
      <bpmn:lane id="Lane_Ops" name="Operations">
        <bpmn:flowNodeRef>Task_Review</bpmn:flowNodeRef>
      </bpmn:lane>
      <bpmn:lane id="Lane_System" name="Payment System">
        <bpmn:flowNodeRef>Start_1</bpmn:flowNodeRef>
        <bpmn:flowNodeRef>Task_Screen</bpmn:flowNodeRef>
        <bpmn:flowNodeRef>Gateway_Hit</bpmn:flowNodeRef>
        <bpmn:flowNodeRef>End_Settled</bpmn:flowNodeRef>
        <bpmn:flowNodeRef>End_Rejected</bpmn:flowNodeRef>
      </bpmn:lane>
    </bpmn:laneSet>

    <bpmn:startEvent id="Start_1" name="Payment received"/>
    <bpmn:serviceTask id="Task_Screen" name="Screen against sanctions list"/>
    <bpmn:exclusiveGateway id="Gateway_Hit" name="Sanctions hit?"/>
    <bpmn:userTask id="Task_Review" name="Investigate alert"/>
    <bpmn:endEvent id="End_Settled" name="Payment settled"/>
    <bpmn:endEvent id="End_Rejected" name="Payment blocked"/>

    <bpmn:boundaryEvent id="Timer_SLA" attachedToRef="Task_Review">
      <bpmn:timerEventDefinition/>
    </bpmn:boundaryEvent>

    <bpmn:sequenceFlow id="F1" sourceRef="Start_1" targetRef="Task_Screen"/>
    <bpmn:sequenceFlow id="F2" sourceRef="Task_Screen" targetRef="Gateway_Hit"/>
    <bpmn:sequenceFlow id="F3" name="No" sourceRef="Gateway_Hit" targetRef="End_Settled"/>
    <bpmn:sequenceFlow id="F4" name="Yes" sourceRef="Gateway_Hit" targetRef="Task_Review"/>
    <bpmn:sequenceFlow id="F5" name="Cleared" sourceRef="Task_Review" targetRef="End_Settled"/>
    <bpmn:sequenceFlow id="F6" name="Confirmed" sourceRef="Task_Review" targetRef="End_Rejected"/>
    <bpmn:sequenceFlow id="F7" name="4h elapsed" sourceRef="Timer_SLA" targetRef="End_Rejected"/>
  </bpmn:process>
</bpmn:definitions>

Models produce this reliably. It is structured, the schema is public, and the element names are unambiguous.

What they produce badly is the <bpmndi:BPMNDiagram> section, the layout coordinates. Every shape needs an x, y, width, and height, and every edge needs waypoints. Ask a model to generate those and you get overlapping boxes and edges routed through tasks, because it is doing geometry without being able to see the result.

So do not ask. Generate the semantic layer, open the file in Camunda Modeler or at bpmn.io, and use the layout function. The tool computes correct coordinates and writes them back into the file. Thirty seconds of work, and it removes the single most common failure mode of AI generated BPMN.

The prompt that produces usable BPMN

The structure that works, with the constraint that matters most at the end:

Generate BPMN 2.0 XML for the process described below.

Requirements:
- One pool. Lanes for each actor named in the description.
- Use serviceTask for system steps, userTask for human steps.
- Every decision is an exclusiveGateway with a named condition on
  each outgoing sequenceFlow.
- Add a timer boundary event for every stated deadline and an error
  boundary event for every stated failure mode.
- At least one end event per distinct outcome. Never merge outcomes.
- Emit the semantic layer only. Omit the BPMNDI section entirely.
- Use stable ids: Task_*, Gateway_*, Start_*, End_*, F* for flows.

Then, separately from the XML, list every assumption you had to make
about actors, decision conditions, deadlines, or failure handling
that the description did not state.

That final instruction is the reason to do this at all. The assumption list is the interview agenda for your session with the process owner, and it is usually more valuable than the diagram. On a recent onboarding process, the model’s list included “the description does not state what happens if the compliance review is not completed, I have assumed the case remains open indefinitely.” That was a real gap, it had been in the procedure document for two years, and nobody had noticed because prose lets you not notice. Turning findings like that into specified behavior is the work in from business requirement to functional specification.

Validating before anyone sees it

Never send a generated BPMN file to a stakeholder without opening it first. Three checks, in order:

Open it. Camunda Modeler or bpmn.io. Both fail loudly on malformed XML or schema violations, and the rendered result tells you immediately whether the layout is usable. This catches almost everything.

Lint it. bpmnlint checks modelling rules rather than syntax: a gateway with unlabelled outgoing flows, a process with no end event, a task with no incoming flow, a disconnected element. These are the defects that survive schema validation and make a model wrong rather than broken.

npx bpmnlint payment-approval.bpmn

Validate in a build step. If the file is committed, validate it against the OMG BPMN 2.0 XSD in CI, the same way you would validate an ISO 20022 message against its schema. A broken diagram file should fail the build, not surprise a stakeholder in a workshop.

Then read it as an analyst. Does every gateway have a labelled condition on every outgoing flow? Does every activity that can fail have an error path? Is there an end event for each real outcome, or has the model quietly merged “settled” and “blocked” into one node? That last one is common and it destroys the model’s meaning. Where the branching gets dense enough that a gateway chain becomes unreadable, a decision table alongside the model handles the combinations better than more gateways.

Maintaining a BPMN model instead of redrawing it

The same loop as every other diagram as code, with one BPMN specific wrinkle.

Commit the .bpmn file to the repository next to the specification. It is XML, so it diffs, though the diff is noisy when the modeler rewrites layout coordinates. Two things keep it readable: use stable element ids, Task_Screen rather than Activity_0x9f2ka, so a semantic change shows up as a semantic diff; and if the noise is still bad, configure git to treat layout-only changes as uninteresting by keeping the semantic file and the laid out file separate.

Then, when the process changes, do not redraw. Give the model the current XML and the change: “add a second approval step for amounts over fifty thousand, performed by the Treasury lane, between screening and settlement.” It returns the modified XML preserving every existing id, you relayout, you commit, and the diff shows exactly the three elements that changed. That is the maintenance property that makes the whole approach worth adopting, and it is impossible with a drawing tool.

One habit worth building: when a process model changes, regenerate the corresponding technical diagram from the same description in the same session. The BPMN model and the sequence diagram describe one process to two audiences, and the failure mode on every project is that one of them gets updated and the other does not.

The takeaway

BPMN is XML, so AI can write it and git can version it, which puts process models on the same maintainable footing as every other diagram as code. Generate the semantic layer only, twelve elements cover almost everything, and let Camunda Modeler or bpmn.io compute the layout. Always ask for the assumption list alongside the model, because the assumptions are where the missing requirements are hiding.

Reach for BPMN when the audience is business, the handoffs matter, or an engine will execute the model. Otherwise a Mermaid diagram is faster and renders everywhere. The system that holds all of it together is diagrams as code with AI. For the deliverable templates around a process model, see Real-World BA Deliverables, and for the prompt library, The Tech BA Prompt Toolkit.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Business Analysis, BPMN, Process Modelling, AI, Documentation