UML Activity Diagrams: A Complete Guide
Activity diagrams model workflows and business processes with the rigor of UML. This guide covers actions, decisions, concurrency with forks and joins, and swimlanes for responsibility.
An activity diagram is UML's answer to the flowchart, and it is the diagram to reach for when you want to model a process: an order fulfillment workflow, an approval chain, an algorithm's control flow, or the steps of a business procedure. It looks familiar to anyone who has seen a flowchart, but it adds precise notation for concurrency, responsibility, and object flow that plain flowcharts lack.
Because they read naturally, activity diagrams are excellent for aligning engineers and non-engineers on how a process should work before it is built. This guide covers the core nodes, how to model parallel work correctly, and how swimlanes assign responsibility. You can build these at /diagrams, and the broader UML context is covered at /diagram-tools/uml-diagram.
The core nodes
Every activity diagram starts with an initial node, a solid filled circle, and ends with an activity final node, a filled circle inside a ring. Between them, the work happens in action nodes, drawn as rounded rectangles labeled with a verb phrase like "Charge Card" or "Send Confirmation". Control flows from node to node along solid arrows, so the diagram reads as a directed path from start to finish.
Decisions are diamonds with one incoming arrow and multiple outgoing arrows, each guarded by a condition in square brackets like [amount > 1000]. The flow follows the branch whose guard is true. A matching merge node, also a diamond, brings alternative branches back together. Keeping decision and merge nodes explicit rather than letting arrows converge arbitrarily keeps the diagram unambiguous.
Modeling concurrency with forks and joins
The feature that sets activity diagrams apart from ordinary flowcharts is first-class support for concurrency. A fork node, drawn as a thick horizontal or vertical bar with one input and several outputs, splits the flow into parallel branches that all proceed at the same time. This is how you model "at this point we start preparing the shipment and sending the receipt simultaneously".
A join node, the same thick bar but with several inputs and one output, synchronizes those branches back together: the flow does not continue past the join until every incoming branch has completed. The fork/join pair is precise about a real distinction that trips up flowcharts, which have no clean way to say "do these two things in parallel and wait for both". If you are modeling anything with genuine concurrency, this is the notation that earns activity diagrams their place.
Swimlanes and responsibility
Activity partitions, universally called swimlanes, divide the diagram into columns or rows, each labeled with the actor, department, or system responsible for the actions inside it. An order process might have swimlanes for Customer, Sales, Warehouse, and Payment System, with each action sitting in the lane of whoever performs it. As the flow crosses lane boundaries, you see responsibility hand off from one party to the next.
Swimlanes turn an activity diagram into a powerful tool for process analysis, because bottlenecks and excessive handoffs become visible. A process where the flow ping-pongs back and forth across three lanes a dozen times is telling you something about coordination cost that no amount of prose would. When you draw a process this way and see the crossings, the redesign often suggests itself.
Activity diagram versus flowchart
People often ask what an activity diagram gives them over a flowchart, and the honest answer is that for a simple linear process, not much. Both have start and end points, actions, and decisions. If your process is a straight line with a couple of branches, a flowchart is fine and lighter weight.
- Activity diagrams have precise fork/join notation for true parallelism; flowcharts do not.
- Swimlanes assign each action to a responsible actor or system, which flowcharts lack by default.
- Activity diagrams can model object flow, showing data passing between actions, not just control flow.
- They are part of UML, so they integrate with the rest of a UML model and its shared vocabulary.
- They support signals and events for time-based and event-driven triggers.
- Flowcharts win on simplicity and universal familiarity for basic, sequential processes.