Document to BPMN: AI Auto-Generation in 2 Minutes (2026)

Almost no organisation maintains BPMN diagrams as the canonical description of its processes. The canonical description lives in meeting transcripts, SOP documents, training manuals, email threads, onboarding guides, Slack channels, and in the heads of whoever has been doing the job longest. The historical pain of BPMN adoption has been the translation from that messy prose substrate to a clean visual notation. AI-native document-to-BPMN flows collapse that translation into a single upload.

The key insight is that natural language describing a process is already structurally similar to BPMN. Sentences identify actors ('the compliance officer reviews'), activities ('reviews the application'), sequence ('and then sends it to legal'), and branches ('unless the amount is above 10,000 pounds, in which case'). A language model that understands those patterns can walk through a document and emit a BPMN structure as it goes. The challenge is not the extraction, it is handling the parts of the prose that are ambiguous, contradictory, or implicit.

The LucidFlow upload flow accepts a broader range of formats than most users expect. The formats are handled by the document parsers in the application: DOCX via mammoth, XLSX via ExcelJS, PPTX via unzipper+XML extraction, and PDF/images as inline binary data fed directly to the Gemini vision model. The practical list is wide enough that you rarely have to pre-convert anything.

• Word documents (.docx): most SOPs, policy documents, process descriptions. Tables inside the document are preserved in the extracted text.
• Excel spreadsheets (.xlsx): task lists, RACI matrices, process inventories. Each sheet is extracted as a CSV-like block with the sheet name as a header.
• PowerPoint (.pptx): workshop slides, training decks, process walkthroughs. Text and notes are extracted; embedded images are not (yet).
• PDFs (.pdf): contracts, policy documents, vendor process descriptions. PDFs are passed to the vision model as inline binary, which preserves layout and handles tables better than text extraction.
• Images (.png, .jpg): photos of whiteboards, hand-drawn flowcharts, screenshots of diagrams from other tools. The vision model reads them directly.
• Plain text and markdown (.txt, .md): meeting notes, chat transcripts, call summaries. Often the cleanest input because there is no format overhead for the parser.
• BPMN 2.0 XML (.bpmn, .xml): existing diagrams from Visio, Camunda, Bizagi, or any BPMN-compliant tool. Imported rather than regenerated, so the original structure is preserved and the KPI-enrichment layer runs on top.

The pipeline has four stages, and understanding each one helps you get better outputs. The first two run server-side before you see anything; the third and fourth are interactive.

Stage 1: Document analysis

The Gemini model reads the documents and produces a structured intermediate representation: a list of process steps with actors, tasks, tools used, estimated durations, and decision points. At this stage the model also detects whether the documents describe one process or several, and whether the perspectives mix as-is (current state), to-be (target state), pain points, and wishlist items. This is the multi-intent classification: if more than one intent has confidence above 0.7, the flow will ask you to disambiguate before proceeding.

Stage 2: Clarification questions

The AI generates 3 to 6 clarifying questions tailored to the specific documents. The very first question is always the detail level: Detailed, Balanced, or Summary: because that controls how granular the resulting diagram will be. Subsequent questions are prioritised: high-priority questions block the mapping (missing a decision criterion, unclear actor responsibility), medium-priority questions fill in important KPI data, low-priority questions are nice-to-have. Each question carries 2 to 4 suggested answers plus a free-text option, so you are not forced into a binary choice.

Stage 3: BPMN generation

With your answers in hand, the model generates the BPMN structure: start event, tasks with KPI payloads (estimated duration, cost, frequency), gateways with correctly-typed branching logic (exclusive vs parallel), end events, and swimlane assignments. The generation step enforces a schema with Zod validation so invalid structures cannot be produced: missing start events, orphaned edges, mislabeled gateway types are all rejected with actionable error messages rather than silently accepted.

Concretely, a single generated task node is a JSON object with this shape, stored in the database and read back by the React Flow canvas:

{
  "id": "Task_Review",
  "type": "task",
  "position": { "x": 240, "y": 120 },
  "data": {
    "label": "Review invoice",
    "role": "Finance",
    "tool": "SAP",
    "description": "Verify PO match and totals.",
    "estimatedDuration": 15,
    "estimatedCost": 8,
    "frequency": { "count": 120, "period": "month" }
  }
}

A Process describes a sequence or flow of Activities in an organization with the objective of carrying out work.

Stage 4: Layout and rendering

The generated BPMN is passed to the ELK layout engine, which runs in a web worker so the main thread is not blocked. ELK positions nodes inside their swimlanes, routes edges to avoid crossings, and produces the coordinates that React Flow uses to render the interactive canvas. The whole pipeline: stages 1 to 4: typically takes 60 to 90 seconds end to end, with clarification question time not counted because that is you, not the model.

A single document almost never describes a single pure process. A typical workshop transcript covers the current as-is process, a proposed to-be redesign, the team's complaints about the current state (pain points), and a list of things they wish existed (wishlist). If the AI treated all of this as one process, the resulting diagram would be a muddle of current tasks, aspirational tasks, and complaints about the approval workflow: structurally incoherent and operationally useless.

The multi-intent classifier addresses this by detecting four canonical intent types: as_is, to_be, wishlist, pain_point, and assigning each process step to one or more of them. When two or more intents have confidence above the 0.7 threshold, the flow surfaces this and asks you which intent(s) to map. If you pick a single intent like as_is, the flow generates that one diagram and stores the other intents as optimization hints on the session for later reference. If you pick 'All detected processes', each intent becomes its own standalone diagram (an as_is, a to_be, a pain_point, a wishlist), generated sequentially. Keeping them as separate artefacts, not fused into one diagram and not overlayed as hover annotations: is the difference between a useful map and a confusing one.

As of 2026, the focus has shifted from mere generation to agentic verification. It is no longer enough for an AI to produce a diagram that looks correct; it must prove its work. Modern pipelines now employ a secondary 'Critic' agent that attempts to find logical flaws or omissions by cross-referencing the generated XML against the source prose.

• Source Citations: Every task and gateway in the generated BPMN now includes a metadata link to the specific paragraph or transcript timestamp it was derived from.
• Regulatory Alignment: The AI automatically checks the process flow against a library of compliance standards to flag potential violations in the 'as-is' state (source: Compliance Automation Report, 2026).
• Hallucination Scoring: Each diagram receives a 'Grounding Score' based on how much of the flow is explicitly stated versus inferred.