Swimlane diagram
A swimlane diagram is a process map organised into horizontal (or vertical) lanes, where each lane represents one role, team, department, or system. Every task lives in exactly one lane — making it visually obvious who is responsible for each step of the process.
In BPMN 2.0 notation, swimlanes are a first-class concept: a pool (the outer box) contains one or more lanes, and every task, event, and gateway lives inside a lane. This is the canonical format for documenting cross-functional processes — order fulfilment, onboarding, incident response, procure-to-pay — anywhere multiple roles hand work between each other.
Swimlane diagram example: bank payment
In BPMN 2.0, "swimlane" covers both pools and lanes. This example is a multi-pool swimlane: a Customer pool and a Bank Teller pool, connected by message flows. Every task sits in the pool of the party that performs it, and the single "Are payment details valid?" gateway sits with the Bank Teller who owns the call. For cross-party processes like this, multiple pools are the readable alternative to packing everything into one pool with many lanes.
Making a payment at a bank
A two-pool BPMN 2.0 collaboration for making a payment at a bank. The Customer pool submits a payment and later receives a receipt; the Bank Teller pool receives the request, verifies the details, and routes through an exclusive gateway ("Are payment details valid?") — processing the transaction and providing a receipt on the yes path, or returning funds on the no path. Two message flows connect the pools: the customer sends the payment request to the bank, and the bank sends the receipt back.
- Customer submits the payment — the Payment Initiated start event fires the Submit Payment task.
- A message flow carries the request to the Bank Teller pool, triggering the Payment Request Received start event.
- Bank Teller verifies the payment details, then the "Are payment details valid?" exclusive gateway decides the path.
- On the no path, Bank Teller returns the funds and the Bank Teller process ends at Payment Rejected.
- On the yes path, Bank Teller processes the payment transaction and provides a receipt, ending at Payment Processed.
- A second message flow delivers the receipt back to the Customer pool, where the Receive Receipt task runs and the Customer process ends at Payment Completed.
How to draw a swimlane diagram in 5 steps
1. List every role, team, or system involved
One swimlane per role. Keep the list short — 3–6 swimlanes is the readable maximum. Combine roles that always act together. If a process crosses organisational boundaries (e.g. customer and bank), put each party in its own pool and connect them with message flows.
2. Order the swimlanes by who acts first
The top swimlane is typically the initiator (customer, requester). Subsequent swimlanes follow the order of hand-offs. This lets the eye trace flow top-to-bottom as well as left-to-right.
3. Add the tasks in each swimlane
Use verb-first task names ("Validate order", not "Order validation"). Place each task in the swimlane of the role that does it — this is the whole point of swimlanes.
4. Add gateways where the path branches
Exclusive gateways (diamonds) for either/or decisions. Parallel gateways for simultaneous paths. Place the gateway in the lane of whoever makes the decision.
5. Add start and end events
A circle at the start (thin border) and one or more at the end (thick border). Multiple ends are fine — every branch needs to terminate.
Swimlane diagram FAQ
What is a swimlane diagram used for?
A swimlane diagram is used whenever you need to show not just what happens in a process but who is responsible for each step. Each lane corresponds to a role, team, department, or system. It's the default choice for documenting cross-functional processes like order fulfilment, onboarding, or incident response.
What is the difference between a flowchart and a swimlane diagram?
A standard flowchart shows sequence (what happens in what order). A swimlane diagram adds accountability (who does each step) by grouping every element into lanes. Every swimlane diagram is a flowchart — but not every flowchart is a swimlane diagram. In BPMN 2.0, swimlanes are a first-class concept.
Should swimlanes be horizontal or vertical?
Horizontal is more common because time/flow reads left-to-right naturally, which matches the way most people scan diagrams. Vertical lanes are occasionally used when the process has many roles and you want the diagram to fit on a portrait page. BA Copilot defaults to horizontal; you can flip orientation at export time.
Can a swimlane contain another pool?
In BPMN 2.0, pools and lanes are nested one-level deep: a pool contains lanes, and each lane contains flow-nodes (tasks, events, gateways). You can represent external parties using separate pools connected by message flows, but you don't put a pool inside a lane.
How do I draw a swimlane diagram quickly?
Describe the process in plain English — mentioning each role by name — and paste it into BA Copilot's AI BPMN generator. The AI will infer the lanes and place every task in the right one. Review and adjust in the drag-and-drop editor. Typical time: ~30 seconds to first draft.
Skip the shape-placement
Describe your process — mention each role by name — and BA Copilot's AI returns a full BPMN swimlane map. One free generation per browser.