Workflow Diagram

A workflow diagram maps how people, roles, and teams complete work together: who does each step, who hands off to whom, who approves, and where work waits. It is a process flow (Process Flow) with WHO added — the operation-centered sequence, now assigned to actors. When you draw the WHO as parallel lanes, it becomes a swimlane flow (Swimlane Flow); this file covers the thinking, that file the lane notation. Near-synonyms: workflow map, cross-functional process map, approval flow.

Difference from a process flow

A process flow says "the application is reviewed." A workflow diagram says "a licensing officer reviews it, and if the amount exceeds $10k, a supervisor must co-sign, and the officer can't proceed until the supervisor does." The additions that matter:

• Roles: which job title/permission level performs each step.
• Handoffs: where responsibility transfers between people — the step most likely to drop the ball (Rummler & Brache built a whole method on this: process failures concentrate in the "white space" between departments, not inside them).
• Dependencies: what can't start until something else finishes; what can run in parallel.
• Approvals: who can say yes, who can say no, what happens on no.
• Wait/blocked states: work sitting in someone's queue.

Enterprise UX lives here

Consumer apps mostly serve one person at a time; enterprise products serve workflows. You can't design an internal tool, admin dashboard, CMS, healthcare system (orders → nursing → pharmacy → administration), education platform (submission → grading → moderation), or government service (application → caseworker → supervisor → notice) without knowing the workflow — because the core screens ARE the workflow made visible: queues ("what's waiting on me?"), status ("where is my item?"), assignments ("whose is it?"), and audit trails ("who did what?"). Related: Permission Flow for what each role may do, Multi-User Flow for real-time multi-actor interaction, Service Blueprint for the customer-facing view of the same machinery.

Example — content publishing workflow

((Client Request received))
  → [PM reviews request, writes brief]        (role: PM)
  —HANDOFF→ [Designer drafts]                 (role: Designer)
       ⏸ BLOCKED until: brief approved; assets from client
       └── assets never arrive → PM chases → (wait…) → escalate
  —HANDOFF→ [Developer builds]                (role: Developer)
       ⏸ BLOCKED until: design approved — by whom? PM or client?
  —HANDOFF→ [QA tests]                        (role: QA)
       ├── pass → continue
       └── fail → back to Developer  (loop — max cycles? who
             decides "good enough"? that's a policy question)
  —HANDOFF→ [Client approves]                 (role: Client — external!)
       ├── approves → [Publish]  (role: PM or auto?)
       │        └── publish fails → Developer notified → retry
       ├── requests changes → back to Designer or Developer
       │        (who triages which? undefined = chaos)
       └── silent for 10 days → ⏸ work parked → reminder → close?
  → ((Published — notify all roles))

Annotations are the point. Every —HANDOFF→ needs a notification ("it's your turn") and context transfer (the next person needs the brief, files, history — not a bare task title). Every ⏸ BLOCKED state needs to be visible: who is it waiting on, since when, and who gets nudged? The waiting and blocked states are where enterprise UX pain concentrates — users describe it as "things disappear into a black hole." A workflow tool that shows every item's holder and age beats a prettier one that doesn't. Note also the external actor: the client doesn't log into your admin tool, so their approval step needs its own lightweight surface (email link, share page).

How to build one

1. List the roles first — real roles with permission boundaries, not org-chart titles. Include external actors and "the system" for automated steps.
2. Map the steps (as in Process Flow), then assign each to one role. A step nobody owns is a bug in the org, and you just found it.
3. Mark every handoff, every approval (with rejection path), every dependency, every wait state.
4. Ask each role: "How do you know when it's your turn?" and "Where does work pile up?" The answers design your notifications and queue screens.
5. Time-stamp reality: how long does work sit at each handoff? Design for the real durations, not the aspirational ones.

Common mistakes

• No owner per step ("the team reviews it" — which human?).
• Approval steps without rejection paths — every approval can be denied, stalled, or bounced with changes; draw all three.
• Invisible blocked states — the #1 enterprise complaint.
• Ignoring external actors because they don't use your tool.
• Loops without limits (QA ↔ Dev forever).
• Designing for the documented workflow, not the observed one — shadow the roles; workarounds ARE the requirements.

Checklist

• Every step has exactly one named role/owner (including "system" and external actors).
• Every handoff has a notification and transfers context, not just a task.
• Every approval has approve / reject / request-changes / no-response paths.
• Every wait/blocked state is visible in the UI: waiting on whom, since when, escalation path.
• Loops have exit conditions and cycle limits.
• Parallel work is marked (what can proceed simultaneously?).
• Validated by shadowing the real roles, not just reading the SOP.
• Role permissions cross-checked with Permission Flow; ≥3 actors → draw it as lanes (Swimlane Flow).

Sources

• Rummler, G. & Brache, A. (1990). Improving Performance: How to Manage the White Space on the Organization Chart — handoffs between functions as the primary failure site; popularized the swimlane view of cross-functional work.
• Object Management Group — BPMN 2.0 specification (omg.org/spec/BPMN; v2.0.2, 2014) — pools/lanes and user tasks as the formal notation for role-assigned work.
• ISO 5807:1985 — base flowchart symbol conventions.