What is a UML activity diagram?
A UML activity diagram is a behavioural diagram that models the flow of control or data through a process. It captures the sequence of actions from start to finish, including conditional branches (decisions), parallel paths (forks and joins), and handoffs between responsible parties (swimlanes). Unlike a sequence diagram — which focuses on which participant sends which message — an activity diagram focuses on what happens and in what order, making it the go-to notation for business process modelling and workflow documentation.
Activity diagrams are formally defined in UML 2.5.1 (ISO/IEC 19505). They are used across software engineering, business analysis, and system design to document everything from user registration flows to complex multi-department approval processes.
Core UML activity diagram notation
Every element in a UML activity diagram carries precise graphical semantics. flow-chart.io generates each as a typed, editable object.
| Element | UML Symbol | Description |
|---|---|---|
| Initial node | Filled circle (●) | The single starting point of the activity. Every activity has exactly one initial node. |
| Action node | Rounded rectangle | An atomic unit of behaviour — a step that does something. Labelled with a verb phrase: "Validate Order", "Send Email", "Update Database". |
| Decision node | Diamond (◇) | A conditional branch. Has one incoming flow and two or more outgoing flows, each labelled with a guard condition in square brackets. Only one outgoing flow is taken. |
| Merge node | Diamond (◇) | Joins multiple incoming conditional flows into one outgoing flow. Like a decision node visually, but semantics are opposite — it does not choose, it re-joins. |
| Fork node | Thick horizontal or vertical bar | Splits one incoming flow into multiple concurrent outgoing flows. All outgoing branches execute simultaneously. |
| Join node | Thick horizontal or vertical bar | Waits for all incoming concurrent flows to complete before emitting a single outgoing flow. Synchronises parallel branches. |
| Object node | Rectangle (no rounded corners) | Represents a typed data object flowing between actions — makes data dependencies explicit. Labelled with the object's type. |
| Swimlane (partition) | Named vertical or horizontal band | Assigns responsibility for actions to a named party — a person, team, system, or organisation. Flows crossing lane boundaries indicate handoffs. |
| Activity final node | Circled filled circle (◎) | Terminates the entire activity. Any concurrent flows still running are cancelled when this node is reached. |
| Flow final node | Circle with X inside | Terminates only the current flow, not the entire activity. Other concurrent branches continue. |
Activity diagram vs. flowchart: key differences
Activity diagrams and flowcharts look similar at first glance, but they differ in important ways.
| Dimension | UML Activity Diagram | Flowchart |
|---|---|---|
| Standard | ISO/IEC 19505 (UML 2.5.1) — formally specified semantics | No governing standard; symbols vary between tools and teams |
| Parallel flows | Fork/join nodes with precise concurrent semantics | No native parallel construct; workarounds vary |
| Responsibility | Swimlanes (activity partitions) — formal handoff notation | Swimlanes exist in some tools but with no formal semantics |
| Data | Object nodes carry typed data tokens between actions | No typed data flow — only control flow |
| Nested activities | Structured activity nodes — sub-activities embedded inline | Not supported natively |
| Best for | UML system models, formal process documentation, tool interchange | Quick ad-hoc process sketches, whiteboard discussions |
Modelling parallel flows with fork and join nodes
Parallel execution is one of the most useful and most misunderstood features of UML activity diagrams. A fork node splits a single incoming flow into multiple concurrent outgoing flows — all of which execute simultaneously. A join node waits for all incoming flows to complete before allowing the process to continue. Together, fork and join nodes model any scenario where multiple things happen at the same time.
Example: an e-commerce order fulfilment process. After payment is confirmed, three actions execute in parallel: reserving inventory, charging the payment method, and sending an order confirmation email. Only after all three complete does the process advance to shipping dispatch. In the activity diagram, a fork node produces three concurrent flows, and a join node re-synchronises them before the "Dispatch Shipment" action.
Use this prompt in flow-chart.io to generate the above diagram:
E-commerce order fulfilment: Customer places an order. Validate payment details — if invalid, send payment failure email and end; if valid, confirm payment. Fork into three parallel paths: (1) Reserve inventory in warehouse system, (2) Charge payment method via payment gateway, (3) Send order confirmation email to customer. Join all three paths. Dispatch shipment. Send shipment tracking email. End. Show swimlanes for Customer, Order Service, Warehouse, Payment Gateway. UML activity diagram.
Swimlanes: modelling responsibility and handoffs
Swimlanes (formally called activity partitions in UML) divide an activity diagram into named bands, each representing a responsible party. When a control flow arrow crosses a lane boundary, it represents a handoff — work moving from one party to another. Swimlanes answer the question "who does what" directly on the diagram, without requiring a separate RACI matrix or written explanation.
- Use swimlanes when a process involves more than one responsible party — department, system, role, or external service.
- Place actions in the lane of the party that performs them, not the party that initiates the request.
- Control flows crossing lane boundaries represent handoffs — review these crossing points to identify coordination costs and integration risks.
- Keep swimlanes to five or fewer per diagram to maintain readability. Use separate diagrams for sub-processes if the number of lanes grows.
- Vertical swimlanes (top-to-bottom flow) work best for time-sequenced processes. Horizontal swimlanes work best for processes with many handoffs between parties at similar stages.
Common use cases for UML activity diagrams
| Domain | Process | Why activity diagram |
|---|---|---|
| Software development | User registration, checkout, authentication flows | Shows every decision branch and error path in a single diagram, making edge cases visible before implementation. |
| Business process management | Invoice approval, HR onboarding, contract review | Swimlanes assign ownership of each step; crossing flows highlight handoffs and waiting time. |
| System integration | Data ingestion pipeline, ETL workflow, message routing | Object nodes show typed data moving between systems; fork/join model parallel processing stages. |
| DevOps / CI-CD | Build, test, deploy pipeline stages | Fork nodes model parallel test suites; join ensures all pass before deploy stage starts. |
| Compliance and audit | GDPR data deletion, SOC 2 access review, change management | Formal UML notation provides an unambiguous, auditable record of the approved process. |
| Algorithm documentation | Machine learning training loop, retry logic, pagination | Loop and decision nodes model conditional repetition with guard conditions more precisely than prose. |
Activity diagram best practices
- Start with one initial node and ensure every flow eventually reaches an activity final node. Diagrams with unreachable actions or dangling flows are a sign of incomplete process modelling.
- Label every decision node's outgoing flows with explicit guard conditions in square brackets — [approved], [rejected], [timeout] — not vague labels like "yes" / "no".
- Use fork and join nodes in matched pairs. Every fork that creates concurrent flows must have a corresponding join that synchronises them before the next dependent step.
- Keep action node labels as verb phrases: "Validate Payment", "Send Confirmation Email". Noun phrases like "Payment Validation" obscure who does what.
- Limit each diagram to one process or sub-process. Use a call behaviour action node to reference sub-activities rather than embedding them all in one diagram.
- Use object nodes to make typed data dependencies explicit when data correctness is a concern — especially in data pipeline and integration diagrams.
- Review lane crossing points: every flow that crosses a swimlane boundary is a potential SLA risk, integration cost, or access control concern.
Frequently asked questions
- What is a UML activity diagram?
- A UML activity diagram is a behavioural diagram that models the flow of control or data through a process. It shows how a series of actions are sequenced — including branches for decisions, forks for parallel paths, and joins where parallel flows re-synchronise. Activity diagrams are defined in UML 2.5.1 (ISO/IEC 19505) and are widely used for business process modelling, workflow documentation, and algorithm design.
- What is the difference between an activity diagram and a flowchart?
- Both model sequential processes with decisions, but activity diagrams are formally specified with precise semantics for every element — fork/join nodes for concurrency, object nodes for typed data, swimlanes for responsibility partitions, and nested structured activities. Flowcharts have no governing standard; symbols and semantics vary between tools. Use activity diagrams when you need formal, tool-interchangeable, or auditable process documentation. Use flowcharts for quick sketches where formality is not required.
- How do I show parallel flows in a UML activity diagram?
- Use a fork node (a thick bar that emits multiple concurrent outgoing flows) to start parallel execution, and a join node (a thick bar that waits for all incoming flows to complete) to re-synchronise them. Every fork should have a matching join before the next step that depends on all parallel branches completing. For example: a fork after "Confirm Payment" can start "Reserve Inventory", "Charge Card", and "Send Confirmation Email" in parallel, with a join before "Dispatch Shipment".
- What are swimlanes in an activity diagram?
- Swimlanes, formally called activity partitions in UML 2.5.1, divide an activity diagram into named horizontal or vertical bands representing responsible parties — a person, team, system, or organisation. Actions placed in a lane belong to that party's responsibility. Flows crossing lane boundaries represent handoffs between parties. Swimlanes make ownership explicit without requiring a separate RACI matrix.
- When should I use an activity diagram instead of a sequence diagram?
- Use an activity diagram when the focus is on what steps happen and in what order, regardless of which participant performs each step. Activity diagrams are ideal for business processes, workflows, and algorithm documentation. Use a sequence diagram when the focus is on which participant sends which message to which other participant and in what order — API contracts, authentication flows, and microservice interactions. Rule of thumb: steps in a process → activity diagram; messages between services → sequence diagram.
- Can I model object flows in a UML activity diagram?
- Yes. Object flows carry typed data objects between actions, represented as rectangles (no rounded corners) labelled with the object type. Object flows make data dependencies explicit — useful in ETL pipelines, data transformation workflows, and any process where the type of data being passed between steps matters for correctness.
- Is the generated activity diagram editable, or is it a static image?
- Fully editable. flow-chart.io generates a typed scene graph, not a raster image. Every action node, decision node, fork bar, join bar, swimlane, and control flow is a named object you can rename, reposition, or delete. You can add new swimlanes, insert a parallel branch, or change a guard condition without rebuilding the diagram. Nothing is flattened to pixels until you export to PNG.