Process mapping workshops

Map the process while people describe it.

The usual sequence is a workshop, a wall of sticky notes, and then a week of someone reconstructing it all in a diagramming tool, guessing at the branches they cannot quite remember. Backlog.cloud collapses that: the walkthrough itself becomes a BPMN 2.0 process model, and anything the room left ambiguous becomes an open question instead of an invented arrow. This page covers how to facilitate the workshop and what comes out.

Map your next walkthrough See a walkthrough become a model

What it is

A walkthrough with the people who live the process

A process mapping workshop puts a facilitator, usually a business analyst, in a room with the people who perform a process, and walks it from trigger to end state. The output is a structured map, conventionally BPMN: swimlanes for roles, tasks in sequence, gateways where the flow branches on a condition. Either as-is, the process as it actually runs, or to-be, the process you intend to build. Map as-is first. A to-be designed without it inherits every problem nobody wrote down.

Attendance follows the lanes. One practitioner per role the process touches, plus someone from each side of every handoff, because the two sides of a handoff never describe it the same way. Managers are welcome for context and thresholds, but the map must come from people who can answer "what did you actually do last Tuesday?" without checking a document.

It counts as a discovery-type meeting, so what it surfaces does double duty: the model itself, plus pain points and open questions that merge into the project's Discovery Pack.

Running the walkthrough

The facilitator's sequence

This doubles as the agenda. A 90-minute workshop spends about ten minutes on the frame, twenty on the happy path, and the rest on branches, handoffs and open questions, because that is where the truth lives.

  1. 1

    Fix the frame

    Name the process, its trigger and its end state before anyone describes a step. "From the moment someone needs to buy something until the supplier is paid" is a frame. "Procurement" is a fog. Agree whether you are mapping as-is or to-be, and do not let the session drift between them.

  2. 2

    Walk it once, happy path only

    Ask the person who does the work to narrate a real, recent instance from trigger to end. No exceptions yet, no opinions yet. You are establishing the spine of the process: the sequence of tasks and who performs each one.

  3. 3

    Walk it again for the branches

    Now probe every step: what happens if this is rejected, late, over a threshold, missing information? Each answer is a gateway with a condition. This pass is where the real process appears, and where the room starts disagreeing with itself. That disagreement is data.

  4. 4

    Chase the handoffs

    Every time work crosses from one role to another, ask how it travels and how long it waits. Handoffs are where processes lose days, and they are exactly what swimlanes exist to expose.

  5. 5

    Name what nobody knows

    Some questions will get three different answers or a shrug. Do not resolve them by committee on the spot and do not let the map paper over them. Park them as explicit open questions. An honest gap beats a fictional branch.

Worked example

A purchase-order walkthrough becomes a model

A fictional workshop mapping purchase-order approval. Eight lines in, the room has produced two lanes' worth of tasks, a threshold rule with a forgotten condition, a hard finance rule, and one honest ambiguity. Watch where each of those ends up.

The walkthrough

Elena (BA): Start from the moment someone needs to buy something. What happens first?

Marcus (Procurement): They raise a purchase order in the portal. Although anything under 500 usually goes on a company card and never touches the portal at all.

Elena (BA): Noted, two entry routes. Stay with the portal route. The PO is raised, then what?

Marcus (Procurement): The line manager approves it. If it is over 5,000 it also goes to finance for a second approval.

Jo (Finance): Over 5,000 or any software purchase, whatever the amount. People forget the software rule constantly and then wonder why their PO is stuck with us.

Elena (BA): Good catch. And if the line manager rejects it?

Marcus (Procurement): Usually the requester edits and resubmits. Honestly it varies, sometimes they just email the manager and argue their case. There is no set route.

Jo (Finance): Whereas if finance rejects, it is dead. No resubmission from our side, the requester starts a new PO from scratch.

Process model: PO approval, as-is

Rendered as a diagram in the dashboard, downloads as BPMN 2.0 XML. Elements shown as extracted, lane by lane.

Requester

  • Purchase need identifiedstartEvent
  • Raise purchase order in portaluserTask
  • Revise and resubmit POuserTask

Line Manager

  • Review purchase orderuserTask
  • Approved?exclusiveGateway

Finance

  • Over 5,000 or software purchase?exclusiveGateway
  • Finance reviewuserTask
  • PO approvedendEvent
  • PO closed after finance rejectionendEvent

The finance gateway carries both conditions Jo stated: over 5,000, or any software purchase. The forgotten rule is now in the model instead of in Jo's head.

Ambiguity, kept honest

"Honestly it varies, sometimes they just email the manager" does not become an invented resubmission branch. It becomes a clarification question on the rejection path, tracked in the Discovery Pack until a follow-up answers it.

Open question: what is the intended route after line-manager rejection, and should informal email appeals be part of the to-be process?

Pain point, into the Discovery Pack

PP-02: purchases under 500 bypass the portal entirely via company cards, so a slice of spend is invisible to the approval process.

"anything under 500 usually goes on a company card and never touches the portal at all"

Requirement and action item

Requirement: the approval flow must apply the software-purchase condition automatically, regardless of amount, rather than relying on requesters remembering it.

Action: Jo to pull six months of finance rejection data so the rejection paths can be sized on the next pass.

Where it lands: the process model lives in the project dashboard as an SVG diagram with a BPMN 2.0 XML download, while the requirement and action item push, after review, to Jira, Azure DevOps or Linear as typed items with owners. Pain points and the open question merge into the Discovery Pack with the changelog recording this workshop as their source.

Common mistakes

Where process mapping goes wrong

Mapping the policy, not the practice. The official process says everything goes through the portal. The practice puts everything under 500 on a company card. If your map matches the process document exactly, you interviewed the document.

Inventing branches to look finished. Nobody in the room knew what happens after a line-manager rejection, but the diagram needed an arrow, so someone drew one. That arrow will be treated as fact by everyone downstream. An explicit open question is worth more than a plausible guess.

Mixing as-is and to-be in one map. Someone describes what happens, someone else describes what should happen, and the diagram fuses them into a process that exists nowhere. Label the session's variant up front and park the other.

Losing a week to transcription. The workshop was sharp, then the map got redrawn from photos and memory five days later, minus the two conditions someone mentioned in passing. Capturing the model from the conversation itself, with each element grounded in what was said, removes the redrawing step and the memory tax with it.

Treating the diagram as the only output. The walkthrough also surfaced a compliance gap, a hard finance rule and an unmeasured rejection rate. Teams that only leave with a diagram leave most of the workshop's value in the room.

FAQ

Process mapping workshops, answered

What is a process mapping workshop?
A facilitated session where the people who run a process describe it step by step while it gets captured as a structured map, usually as BPMN with swimlanes per role. Run well, it surfaces the branches, thresholds and handoffs that never appear in the official process document. It is one of the discovery-type meetings, so its findings also feed the project Discovery Pack.
Who should attend a process mapping workshop?
A facilitator, the people who actually perform each role in the process, and ideally one person from each side of every handoff. Keep it to the roles the process touches. The purchase-order example on this page needed exactly three people: the facilitator, procurement and finance. What you cannot do without is the practitioner. A manager describing the steps someone else performs produces a map of assumptions.
What is the difference between as-is and to-be process mapping?
As-is maps the process as it runs today, including the workarounds. To-be maps the process you intend to build. Map as-is first, because a to-be designed without the as-is quietly inherits every problem nobody wrote down. Backlog.cloud supports both variants: you choose which one a session is producing, and the model is labelled accordingly.
How does Backlog.cloud turn a conversation into a BPMN diagram?
The extraction engine listens to the walkthrough and produces a validated process graph: lanes, tasks, gateways with conditions, and events, each grounded in what was said. The graph is laid out deterministically and rendered as a diagram in the dashboard, and it compiles to BPMN 2.0 XML on download, following the OMG BPMN 2.0 specification, so it opens in standard BPMN tooling.
What happens when the room is vague or contradicts itself?
The ambiguity is preserved instead of resolved by guesswork. "Honestly it varies" does not become an invented branch. It becomes a clarification question attached to that part of the process, tracked in the Discovery Pack until a follow-up answers it. A process model is only useful if every branch in it was actually said by someone.
What else comes out of a process mapping workshop besides the diagram?
Requirements, when the conversation states what a future process must do. Pain points, which merge into the Discovery Pack with stable reference codes. Decisions, when the room settles a rule. And action items with owners, such as chasing the data that verifies a claim. All of it lands in a review queue, anchored to verbatim quotes, before anything is pushed.
Do I need the meeting bot on the call, or can I upload a recording?
Either works. Paste the Zoom, Microsoft Teams or Google Meet link and the bot joins live, or upload the recording, paste the transcript, or photograph the whiteboard afterwards. The same extraction runs on all of them.

Keep going

Related workflows and resources

BPMN process models

The artefact in detail: lanes, gateways, validation and XML export.

BPMN guide

The notation itself: elements, conventions and how to read a model.

Discovery meetings

The wider discovery practice and the Discovery Pack it maintains.

Transcript to BPMN

Already recorded the walkthrough? Turn the transcript into the model.

Meeting to backlog

The wider workflow: one conversation, twelve artefact types.

For business analysts

How BAs run discovery, requirements and process work in one place.

Run the workshop. Leave with the model.

Backlog.cloud listens to the walkthrough and produces a validated BPMN 2.0 process model, plus the requirements, pain points and open questions the room surfaced. Review everything before it goes anywhere. 3 free generations, no card.

Start with a free account See pricing