A swimlane flowchart (cross-functional flowchart) is an ordinary flowchart split into lanes, one per role, so you see both what happens and who does it. The sample follows an expense claim from employee to manager to finance. It is not UML: UML covers software structure and behaviour; swimlanes, BPMN and journey maps are the other standard notations used alongside it for business processes.
1. The Diagram
The employee starts the process by submitting a claim with receipts attached.
The arrow down into the Manager lane is a hand-off: the claim now waits in the manager's queue.
The manager reviews it and decides Approved?. A No sends it back up to the employee as Revise claim, which loops into a new submission.
On Yes the claim crosses into the Finance lane, where receipts are audited against policy.
Receipts OK? fails if a receipt is missing; the long red arrow returns the claim to the employee again, skipping the manager.
When everything checks out, Finance reimburses on the next payroll run and the process ends.
2. How to Read It
The symbols are the classic ANSI/ISO 5807 flowchart shapes. The only addition is the lane. Count the arrows that cross lane lines: each one is a hand-off where work waits and errors creep in, which is exactly what process-improvement teams look for.
3. Variant: Hiring with Vertical Lanes
Lanes can run vertically too, which suits tall processes viewed on a page or slide. Here a hiring process shows two rejection points converging on one Send rejection step, and a successful path that ends back with the candidate. Pick the orientation that keeps arrows mostly in one direction.
4. Pros, Cons, and When to Use
Pros
Readable by anyone after a minute; no training needed.
Makes ownership and hand-offs between teams obvious.
Fast to draw on a whiteboard during a workshop.
Loops and rework paths stand out, pointing to waste.
Supported by every drawing tool and by Mermaid subgraphs.
Cons
No standard semantics for waiting, timers or messages.
Parallel work is awkward to show without BPMN or UML gateways/forks.
Large processes spread into very wide diagrams.
Not executable; it documents but cannot run the process.
Lane order is arbitrary, so long back-arrows are common.
When to use
Explaining a current process to stakeholders.
Spotting bottlenecks and unnecessary hand-offs.
Onboarding guides and standard operating procedures.
When not to use
Processes with timeouts, events and parallel branches that must be precise (use BPMN).
Software control flow (use a UML activity diagram).
5. As Diagrams-as-Code
In Mermaid, lanes are subgraphs. Mermaid places them automatically, so the layout will not match exactly, but it renders in GitHub and most wikis:
flowchart TB
subgraph Employee
S([Start]) --> SUB[Submit claim]
REV[Revise claim]
end
subgraph Manager
RV[Review claim] --> A{Approved?}
end
subgraph Finance
AU[Audit receipts] --> OK{Receipts OK?}
OK -- Yes --> PAY[Reimburse] --> E([End])
end
SUB --> RV
A -- No --> REV --> SUB
A -- Yes --> AU
OK -- No --> REV