Multi-User Flow

A multi-user flow maps a process that several people — usually in different roles — complete together: collaboration, handoffs, review/approval cycles, and the notifications that stitch the actors together. A single-user flow asks "what does the user do next?"; a multi-user flow adds the harder questions: "who is the next step WAITING on, how do they find out it's their turn, and what does everyone else see in the meantime?"

Near-synonyms and neighbors: cross-functional flow, approval flow, handoff flow. It overlaps with swimlane diagrams (Swimlane Flow — lanes per actor) and workflow diagrams (Workflow Diagram); use this file for the design questions, those for notation and operational framing; backstage systems go in Service Blueprint.

When to use one

Wherever value requires more than one person: marketplaces (buyer ↔ seller ↔ platform), collaboration and project-management tools (assign → do → review), education (student ↔ instructor ↔ admin), healthcare (patient ↔ clinician ↔ pharmacy), service platforms (requester ↔ provider ↔ dispatcher), and admin dashboards (the admin is the second user of every user's action — approving, moderating, supporting). If your permission matrix (Permission Flow) has more than one column, you have multi-user flows to design.

What it answers

Who are the actors, and which step belongs to whom?
Where are the handoffs, and how is each one announced (notification, assignment, queue)?
Where does the process WAIT, on whom, for how long, and what happens when they don't act (reminders, escalation, expiry)?
What does each actor see at every step — including the steps that aren't theirs?
Which branches reject, return, or cancel, and who gets told?

Notation

Two text conventions, by complexity:

One line per actor turn (linear processes): prefix each step with the actor — readable as a script, used in the example below.
Compact swimlane (parallel work, 3+ actors): one column per actor, time flowing down — see Swimlane Flow for the full treatment and when to graduate to BPMN-style tooling.

Example — design request pipeline

CLIENT     Submit request ─────────────────────────────▶ [waiting]
             sees: "Submitted — designer review, typically 2 days"
             (status + expectation, not silence)
DESIGNER   ◀─ notified: new request in queue
           Review ──ok──▶ estimate attached ──▶ to Admin
             │
             └─ needs info ──▶ back to CLIENT with specific
                  questions (client notified; request shows
                  "waiting on you" — the ball's owner is explicit)
ADMIN      ◀─ notified: estimate awaiting approval
           Approve ──▶ to Developer
             ├─ Reject ──▶ CLIENT + DESIGNER notified with reason;
             │     client sees next options (revise / withdraw),
             │     not a bare "Rejected"
             └─ No action 3 days ──▶ reminder ──▶ 7 days ──▶
                   escalate to owner (stalled ≠ cancelled)
DEVELOPER  ◀─ notified + assigned
           Implement ──done──▶ CLIENT notified: review the result
             └─ blocked ──▶ back to DESIGNER (client status
                  updates to "in progress — revised estimate")
CLIENT     Accept ──▶ closed  /  Request changes ──▶ bounded loop
             (e.g., 2 revision rounds, then Admin arbitrates)

The waiting states — the neglected half of multi-user UX

Design effort goes to the actor whose turn it is; calendar time is spent by the actors whose turn it isn't. For every wait, design:

Status the waiter can see: where the item is, who has it, since when, and a realistic expectation ("typically 2 days") — visibility of system status applies to human systems too.
The nudge path: can the waiter send a polite reminder? Does the system remind automatically? When does waiting escalate?
The holder's queue: the person sitting on the work needs a visible pile ("3 awaiting your approval"), or the wait is caused by your product's silence, not their negligence.
Timeout rules: what expiry, auto-approval, or reassignment happens when a required actor never acts (vacation, departure) — every human step needs a non-human exit.

Async vs. real-time branches

The same process forks by tempo, and the design differs:

Async (the default above): notifications carry the handoffs; each actor works alone; conflicts are rare but staleness is common — show "updated since you last looked" and re-validate before acting on old data.
Real-time (co-editing, live support, auctions): presence ("who's here"), live cursors/typing indicators, and conflict handling move to the foreground; the notification layer quiets down because the other actor is visibly present. Concurrent-edit conflict UX: Feedback, Loading, Errors & Recovery (sync-conflict section).
Most products need both — a real-time session inside an async process (a live review call mid-approval); map which steps are which.

Common mistakes

Designing only actor #1's experience; approvers get a bare admin table, waiters get nothing.
Rejections without reasons or next steps — the error-flow dead-end rule (Error Flow) applies to human rejections too.
Unbounded review loops with no arbitration exit.
Notification spam on every micro-event, training all actors to ignore the one that matters (see Notifications & Communication; routes in Notification Flows).
No handling for the missing actor: sole approver leaves, process freezes forever. And letting an actor compose work the permission matrix won't let them submit (Permission Flow).

Checklist

All actors listed, including system/automated actors and "absent" states for each human one.
Every handoff names its trigger and its notification (who is told, through what channel).
Every waiting state shows status + holder + expectation to the waiter, and a queue to the holder.
Reminders, escalation, and timeout rules defined for every human-dependent step.
Reject/return branches carry reasons and route somewhere; revision loops are bounded.
Async vs. real-time decided per step; staleness and conflicts handled accordingly.
Each actor's view of each step is designed (walk the flow once per role — the multi-user equivalent of the state inventory in State Flow).

Sources

Object Management Group — BPMN 2.0 specification (omg.org/bpmn) — standard notation for multi-actor processes, pools, and lanes.
Nielsen Norman Group — "Service Blueprints 101" (nngroup.com) — mapping multiple actors and backstage work over time.
Kalbach, J. (2020). Mapping Experiences, 2nd ed. O'Reilly — alignment diagrams spanning actors and organizations.
Waiting-state guidance ("status + holder + expectation") is this library's convention, applying Nielsen's visibility-of-system- status heuristic (nngroup.com/articles/ten-usability-heuristics/) to human-in-the-loop processes.