Swimlane Diagram Example: Cross-Functional Flowcharts That Show Every Handoff

A customer asks for a $40 refund on Monday. Support approves it within the hour and forwards it to finance, which issues refunds in a Thursday batch. The bank can then take 5 to 10 business days to show the credit. Ten days after asking, with nothing on their statement, the customer disputes the charge.

Every team did its job on time. The delay lived between the teams, in the queues where the request waited for its next owner. A plain flowchart of this process looks harmless. A swimlane diagram puts each step in the lane of whoever does it, and the trouble shows up as arrows crossing lanes.

This post explains swimlane diagrams and when to use one instead of a flowchart or BPMN, then works through a refund example: symbols, handoffs, fixes and drawing tips.

What a swimlane diagram is

A swimlane diagram is a flowchart divided into parallel lanes, one per actor: a person, a role, a team or a system. Each step sits in the lane of whoever performs it. The arrows still give the order; the lanes add ownership. Cross-functional flowchart, swim lane diagram and swimlane process map are other names for the same thing.

An arrow inside a lane is work moving within a team. An arrow that crosses a lane boundary is a handoff: the work changes owner, and it usually waits in a queue before anyone touches it.

In Improving Performance, first published in 1990, Geary Rummler and Alan Brache argued that "the greatest opportunities for performance improvement often lie in the functional interfaces," where work passes between departments: the white space on the organization chart, as their subtitle puts it. A swimlane diagram draws that white space.

Swimlane diagram, flowchart or BPMN?

Pick by the question you need answered. If it is "what happens next," a flowchart is enough, like the incident response flowchart that one on-call engineer follows. If it is "who has this now, and how long has it waited," you need lanes. Choose BPMN when a process engine will run the model, or when events and message flows between organizations must be exact. The BPMN 2.0.2 specification calls its pools and lanes swimlanes and leaves the meaning of a lane to the modeler; the BPMN diagram example covers that notation.

The example: a refund request, step by step

An online store handles refunds with four actors: the customer, support, finance and the payment system (payment provider plus billing). The example policy accepts refunds within 30 days, lets support approve refunds under $100 and sends larger ones to finance.

1. The customer requests a refund.
2. Support checks the order against the refund policy.
3. If the request is outside the policy, support sends a decline with the reason.
4. If it is under $100, support approves it and issues the refund the same day.
5. If it is $100 or more, finance reviews it. If finance finds a reason to decline, support explains the decision to the customer.
6. The payment system refunds the original payment method and emails a confirmation.
7. The bank shows the credit about 5 to 10 business days later, according to Stripe's refund documentation.

Swimlane diagram symbols

Resist adding more: every extra symbol is one more thing a finance analyst must learn before checking your work.

What the lanes reveal

Handoffs

Count the arrows that cross a lane boundary. A refund under $100 crosses three times: customer to support, support to the payment system, payment system back to the customer. A refund of $100 or more crosses four times, and so does a request that finance declines. Before the threshold existed, every refund took a four-handoff path. Each handoff is a queue; in the opening story, the work took minutes and the waiting took days.

Waits and rework loops

Waits hide at handoffs, so write them on the arrows. To measure the time per step and between steps in detail, draw a value stream map.

Rework loops are arrows back to a lane the work already visited. The finance decline returns to support on purpose, because support owns the customer conversation. Support asking the customer for an order number the form could have required is pure waste.

Missing owners

A step you cannot place in a lane is an ownership gap. Check failed refunds: Stripe notes that a refund can fail, for example when the customer's bank account is closed, that the money can take up to 30 days to return to your balance, and that you must build your own logic to tell customers or your team. If no lane owns that step, nobody will.

Improving the process from the diagram

1. Remove a handoff. Let support issue small refunds directly, which takes finance's queue out of every refund under the threshold. Payment providers allow this without full access: Stripe's Refund Analyst role can view and refund payments but cannot create payments or see the balance (at the time of writing, November 2026).
2. Add an approval threshold. Choose it from data: sort last quarter's refunds by amount and see how many requests, and how much money, fall under each candidate. Write the number into the decision itself so nobody has to look it up. If the limit must be enforced rather than trusted, check it in your refund tool before it calls the payment API.
3. Put a target on every handoff, written on the arrow: support replies within 1 business day, finance decides within 2. Then a small refund is issued within 1 business day and a large one within 3. The bank's 5 to 10 business days are outside your control, so say so in the confirmation email.

Horizontal or vertical lanes

BPMN allows lanes in either direction. The difference is practical:

Pick one direction for a set of related diagrams so readers never have to reorient.

The refund request swimlane diagram

How to read it:

• Four lanes, top to bottom: customer, support, finance and the payment system.
• Yes always exits to the right, No downward. Each question is phrased so that Yes means something needs attention: outside the policy, $100 or more, a reason to decline.
• Green is the refund path. Requests under $100 drop from support straight to the payment system and never enter the finance lane.
• Red is the decline path. Both declines end with support sending the reason to the customer.
• Handoff labels carry the targets; the dashed arrow is the bank's 5 to 10 business days.
• The Markdown block lists the policy, the targets and the handoffs per path.

Drawing swimlane diagrams clearly

• One owner per lane. Name lanes after roles, teams or systems, not people; a lane named Dana is wrong after the next reorganization.
• Start every box with a verb: "Check order and refund policy," not "Order check."
• Label every decision exit, and keep each answer on the same side of every diamond.
• Order lanes by traffic, so most handoffs cross a single boundary. Skip a lane only on purpose, as the small refund does here.
• Write waits on the handoffs. Waiting time stays invisible until someone writes it down.
• Leave out system internals. API calls and webhooks belong in an architecture view such as the payment gateway integration diagram.
• Draw the current process and the proposal separately, so nobody mistakes the plan for today.
• End every path in a terminator, and split the diagram if it needs more than six or seven lanes.

Build it in Archboard

1. Sign in with Google or GitHub and create a diagram, or open the cross-functional flowchart template, which already has lanes.
2. Add a Pool from the BPMN pack named Refund request process, with four lanes: Customer, Support, Finance and Payment system.
3. From the Flowchart pack, add three Terminator nodes to the Customer lane: Request refund, Request closed and Refund received.
4. In Support, add a Process to check the order, two Decision nodes (Outside refund policy?, $100 or more?) and a Process to send the decline.
5. In Finance, add a Process (Review refund) and a Decision (Reason to decline?). In Payment system, add a Process for the refund and a Document for the confirmation email.
6. Connect the steps with each Yes to the right and each No downward. Label the handoffs with their targets, color the refund path green and the decline path red, and dash the bank's wait.
7. Add a Markdown block from the Core pack with the policy and targets, plus two Text notes.

If the process already exists as a Mermaid flowchart, the Mermaid to diagram tool turns it into an editable first draft. A Free diagram holds 15 diagram nodes, so a longer process needs Pro or a second diagram. The example uses 13 diagram nodes, within the Free plan.

FAQ

What is a swimlane diagram? A flowchart divided into lanes, one per person, team or system, with each step in the lane of whoever does it. Arrows that cross a lane boundary are handoffs.

What is the difference between a swimlane diagram and a flowchart? A flowchart shows the order of steps and decisions. A swimlane diagram adds ownership, which makes handoffs, waits and steps without an owner visible.

Is a cross-functional flowchart the same as a swimlane diagram? Yes, the names are interchangeable, as is swimlane process map. BPMN also uses lanes, but inside pools and with a stricter notation.

Should swimlanes be horizontal or vertical? Either works. Horizontal lanes suit long processes on wide screens; vertical lanes suit documents and phones that scroll down. Pick one per set of diagrams.

Can a system have its own lane? Yes. A payment provider or scheduler that does work on its own deserves a lane; the BPMN specification lists systems among typical uses of lanes.

Start free — one seat, no credit card.