Process models from meetings
Describe the process out loud. Get the BPMN diagram.
In a process mapping workshop, someone who lives the process explains how work actually moves: who touches it, where it forks, how it ends. Backlog.cloud turns that explanation into a validated process graph, renders it as a diagram in the dashboard, and exports it as standard BPMN 2.0 XML. The person talking never draws a box.
How it works
Conversation to diagram, in four checkable stages
The model never draws freehand and never writes XML directly. Each stage constrains the next, which is why the output is a diagram you can trust rather than a picture that merely looks like one.
Stage 1
Extraction to a process graph
The transcript becomes structured elements: lanes for each actor, tasks for each step, gateways for each decision, events for starts and ends, and the flows connecting them. Every element traces back to what was said.
Stage 2
Validation
The graph is checked for structural correctness before anything renders. Gateways must have their outgoing paths, flows must connect real elements, the process must start and end. Gaps become clarification needs, not silent guesses.
Stage 3
Deterministic layout
Positions are computed by algorithm, not aesthetics. The same graph always lays out the same way: lanes stacked, flow left to right, no overlapping lines. Regenerate the model and the diagram does not reshuffle underneath you.
Stage 4
Render and export
The dashboard renders the model as an SVG diagram you can read in the review queue. Downloading compiles the graph to BPMN 2.0 XML conforming to the OMG specification, so it opens in tools that speak the standard.
The standard itself is published by the OMG at omg.org/spec/BPMN/2.0.2. For a plain-language tour of the notation, start with our BPMN guide.
Before and after
Six lines of workshop dialogue become a claims process model
A fictional process mapping workshop at an insurer, and the structure Backlog.cloud extracts from it. The flow below is shown as text for the page. In the dashboard it is a rendered diagram.
What was said
Nadia (Claims manager): A claim comes in through the portal or by phone. Either way it lands with a claims handler, who checks the policy is active and the cover applies.
Tom (Claims handler): If the policy has lapsed we decline it there and then. The letter goes out the same day.
Nadia (Claims manager): For live policies, anything under two thousand pounds the handler settles directly. No sign-off needed.
Tom (Claims handler): Over two thousand it goes to a senior assessor. They can approve it, or send it back to us with questions.
Priti (BA, facilitating): Where do fraud checks happen in all of this?
Nadia (Claims manager): Only on the over-two-thousand route. The assessor runs the fraud screen before they approve anything.
Lane: Claims handler
- startEventClaim received · Portal or phone
- taskCheck policy is active and cover applies
- gatewayPolicy active? · No: decline claim, send letter same day, end. Yes: continue
- gatewayClaim value over 2,000 GBP? · No: settle directly, end. Yes: hand over to senior assessor
- taskSettle claim directly · Under-threshold route
- endEventClaim settled or declined
Lane: Senior assessor
- taskRun fraud screen · Over-threshold route only
- taskAssess claim
- gatewayApprove? · Approve: claim settled, end. Questions: return to claims handler
Clarification needed, not invented
The workshop did not say what the handler does when the assessor returns a claim with questions. Resubmit to the same assessor? Contact the customer first? The model records this as an open question instead of drawing a loop nobody described.
Notice the fraud screen sits only on the over-threshold route, in the assessor lane, exactly as Nadia answered Priti's question. Nothing in the model exists without a sentence behind it.
The notation, plainly
Four building blocks, no BPMN training required
BPMN has a deep vocabulary, but nearly every real process reads through four elements. The person in the workshop never needs to know any of this. It is how the output is organised, not what the input demands.
Swimlanes
Who does what. One lane per role or team, so responsibility is visible at a glance. In the example, the claims handler and the senior assessor each get a lane, straight from how the room described the split.
Tasks
The actual work: check the policy, run the fraud screen, settle the claim. Each verbal step becomes one task with a verb-first label, placed in the lane of whoever said they do it.
Gateways
The decision points, drawn as diamonds. "If the policy has lapsed" and "over two thousand" are both gateways, each with its condition named and every outgoing path accounted for.
Events
How the process starts and how it can end. A claim arriving is a start event. Settled and declined are separate end events, because they are genuinely different outcomes.
As-is and to-be
Model the process you have, then the one you want
Every process model carries an explicit state: as-is or to-be. The claims example above is as-is, the process as it runs today, lapsed-policy declines and all. That is usually where a business analyst starts, because you cannot redesign a process you have not honestly described.
The to-be variant is a separate model, generated the same way from the workshop where the team designs the future state. Keep both against the project and the change itself becomes reviewable: here is the flow we run, here is the flow we are building towards, and the difference between them is the work. That difference usually feeds directly into requirements from the same discovery effort.
Honest limits
Ambiguity produces questions, not fiction
People describe processes the way they experience them, which means gaps, detours and "oh, unless it is a Friday". A verbal walkthrough is never complete on the first pass. The wrong response to that is a tool that fills the gaps with plausible inventions, because an invented branch in a process diagram looks exactly as authoritative as a real one.
Backlog.cloud takes the other path. Where the conversation is ambiguous or silent, the model surfaces a named clarification: what happens to returned claims, who handles the phone route out of hours, whether the fraud screen can reject outright. Those questions go back to the room, the room answers, and the model gets regenerated complete. A diagram with three honest open questions beats a clean one with three hidden guesses.
This also sets expectations correctly: a first-pass model from a rambling workshop is a strong draft plus a question list, not a finished artefact. That is precisely what a good analyst produces after a first workshop too. It just takes them a day instead of a minute.
When the model is right, it leaves as BPMN 2.0 XML, the OMG standard, with layout included. Process models stay with the project in the dashboard rather than pushing to a work management platform, because a diagram is not a backlog item. The stories and requirements from the same meeting push as normal.
FAQ
BPMN process models, answered
- How does a conversation become a BPMN diagram?
- In stages, each one checkable. The extraction engine turns the transcript into a process graph: lanes, tasks, gateways, events and the flows between them. That graph is validated for structural correctness, so no dangling branches or unreachable steps. A deterministic layout algorithm positions everything, the dashboard renders it as an SVG diagram, and downloading compiles the graph to BPMN 2.0 XML.
- Is the export real BPMN 2.0?
- Yes. The download is BPMN 2.0 XML conforming to the OMG standard (the specification lives at omg.org/spec/BPMN/2.0.2), including diagram interchange information so the layout travels with the file. It opens in tools that read BPMN 2.0, which is the point of exporting to a standard rather than an image.
- What does "validated process graph" actually mean?
- The model never writes XML directly. It emits a structured graph that is checked before anything renders: every gateway has its outgoing paths, every path leads somewhere, every task sits in a lane, start and end events exist. If the conversation did not support a complete flow, the gap surfaces as a clarification need rather than a broken diagram.
- What happens when the verbal description is ambiguous?
- The model flags it instead of guessing. In the claims example, nobody said what the handler does after the assessor returns a claim with questions, so that arrives as a named clarification, not an invented loop. A diagram that quietly fabricates branches is worse than no diagram, because it looks authoritative.
- Can it do as-is and to-be versions of the same process?
- Yes. Process models carry an explicit as-is or to-be state. Map the current claims process in one workshop, then model the redesigned version as a separate to-be variant, and you have both ends of the change on record.
- Which meetings produce process models?
- Process mapping workshops are the natural home, and discovery workshops produce them too. Backlog.cloud knows the meeting type and listens accordingly: in a process mapping session it is listening for actors, sequences, conditions and handoffs, not user stories.
- Does the diagram push to Jira like other artefacts?
- No, deliberately. A process model is not a backlog item, so there is nothing sensible to push to a work management platform. It lives with the project in the dashboard, rendered as a diagram, and exports as BPMN 2.0 XML. The stories and requirements from the same meeting still flow to your platform as normal.
- Do I need to know BPMN notation to use this?
- No. The person in the workshop just describes the process in normal language. The notation is the output, not the input. Reading the result takes about two minutes of orientation: boxes are work, diamonds are decisions, lanes are people. The full vocabulary is covered in our BPMN guide.
Keep going
Related workflows and resources
Process mapping workshops
How to run the meeting that produces a clean first-pass model.
BPMN guide
The notation in plain language: lanes, tasks, gateways, events.
Transcript to requirements
The document artefact that usually pairs with a process model.
Transcript to BPMN
Already have the recording? Start from the transcript instead.
Meeting to backlog
The wider workflow: one conversation, twelve artefact types.
For business analysts
Where process models fit in the BA discovery toolkit.
Your next workshop could end with the diagram drawn
Create a free account, run Backlog.cloud on a process mapping session, and review the model it extracts. Rendered in the dashboard, exported as BPMN 2.0 XML. 3 free generations, no card.