UML: Sequence, Activity & State Diagrams

Swimlanes & Parallel Activities

18 min Lesson 6 of 10

Swimlanes & Parallel Activities

An activity diagram already shows you what happens in a process. Add swimlanes and fork/join bars and it also answers who does each step and which steps run at the same time. Those two additions transform a simple flowchart into a cross-functional blueprint that business stakeholders, developers, and testers can all read from the same page.

What Is a Swimlane?

A swimlane (formally called a partition in UML 2) is a vertical or horizontal band that groups actions by the actor, role, system component, or organisational unit responsible for them. The name borrows from lane markings in a swimming pool: each swimmer stays in their own lane. In a diagram, every action sits inside exactly one lane, making responsibility unambiguous at a glance.

Common partition choices in business analysis:

By role — Customer, Clerk, Manager, System.
By department — Sales, Warehouse, Finance, Shipping.
By system — Mobile App, Backend API, Payment Gateway, Email Service.

One lane per responsibility, not per person. If three clerks all do the same kind of work, they share one lane labelled Clerk. Swimlanes model responsibility classes, not headcounts.

Fork and Join Bars

Real processes frequently split into concurrent threads that must all finish before the process continues. UML activity diagrams represent this with two special notations:

Fork bar — a thick, solid horizontal (or vertical) bar with one incoming flow and two or more outgoing flows. The fork fires all outgoing paths simultaneously. Think of it as "start all of these in parallel."
Join bar — the mirror image: a thick bar with two or more incoming flows and one outgoing flow. The join waits until every incoming path has completed before passing the token forward. Think of it as "wait for all of these to finish."

Together, a fork and its matching join bracket a parallel region. Everything inside that region can proceed concurrently. Outside it, execution is sequential again.

Match every fork with a join. A fork without a corresponding join means some paths never converge — usually a modelling error. Draw the join explicitly even if the diagram looks more crowded; clarity beats compactness every time.

Diagram 1: Online Order Fulfilment with Swimlanes

Consider an online store order-fulfilment process. When a customer places an order, three departments act in parallel: the Warehouse picks and packs the goods, the Finance department charges the payment, and the IT System sends an order-confirmation email. All three must complete before the Shipping department dispatches the parcel.

Online order fulfilment: the fork bar launches three parallel threads (Warehouse, Finance, IT System); the join bar blocks until all three complete before Shipping dispatches the parcel.

Reading the Diagram

Walk through the diagram element by element:

The filled black circle (start node) sits in the Customer lane — the process begins when a customer places an order.
The fork bar has one arrow in and three arrows out. The moment the fork is reached, all three outgoing paths activate simultaneously: the Warehouse starts picking, Finance charges the card, and the IT System fires the confirmation email. None of these waits for the others.
The join bar has three arrows in and one out. The token cannot pass the join until all three upstream paths deliver their token — meaning the parcel cannot be dispatched until goods are packed, payment is cleared, and the email has been sent.
After the join, execution returns to a single sequential thread in the Shipping lane, and eventually the Customer receives a delivery notice.
The bullseye (flow final node) terminates the process.

Do not confuse a fork with a decision diamond. A decision (diamond) routes the token down one branch based on a condition. A fork sends the token down all branches at once. The thick bar is the visual signal: if you see a diamond, it is a choice; if you see a solid thick bar, it is parallelism.

Diagram 2: Library Book Loan Process

For a second example, consider a library's book loan and return process. When a member requests a loan, two things happen in parallel: the system reserves the book in the catalogue, and a librarian fetches the physical copy from the shelf. When both are done, the librarian issues the book to the member.

Library book loan: a fork splits into fetching the physical book (Librarian) and reserving it in the system (Library System); both must complete before the book is issued.

Drawing a Swimlane Diagram: Step-by-Step

Identify the actors. List every role, department, or system that performs at least one action. Each becomes a lane.
Sequence the actions. Write out the process in plain language first. Identify which actions depend on previous ones and which can overlap.
Allocate actions to lanes. Place each action inside the lane of the party responsible for it. If you are unsure, ask "who is accountable if this step fails?"
Identify parallel regions. Look for pairs of actions that have no dependency on each other and can start at the same time. Bracket them with a fork bar at the start and a join bar at the end.
Verify completeness. Every path must eventually reach the end node. No action should be orphaned without an incoming or outgoing flow.

Keep lanes to five or fewer. More than five lanes on a single diagram usually signals that the process should be broken into sub-diagrams. A diagram too wide to print on one page is a diagram too complex for a single meeting.

Common Analysis Insights from Swimlane Diagrams

Swimlane diagrams are one of the most powerful tools for process improvement because they make responsibility gaps and hand-off delays visible:

Hand-off bottlenecks. An arrow crossing from one lane to another is a hand-off. Clusters of crossing arrows between two lanes often indicate a communication bottleneck worth investigating.
Responsibility gaps. If an action does not clearly belong to any lane, it reveals an undefined ownership — a common source of process failures in real organisations.
Unnecessary sequentialisation. When you spot two actions that are both in the same lane and have no data dependency, ask whether they truly must be sequential or whether one could start earlier. The diagram makes this conversation concrete.
Over-burdened lanes. A lane with far more actions than others may indicate a bottleneck role or a system component that is a single point of failure.

In the next lesson we move to state machine diagrams — a completely different kind of behavioural model that describes how a single object (such as an order or a booking) changes state over its lifetime. Where swimlane activity diagrams show processes unfolding over time, state machines show the life history of a thing.