Start With the Workflow in Front of You
When I have a workflow that involves multiple roles, branching decisions, and a mix of manual and system steps, the first tool I reach for is an activity diagram. It gives me a single view of what happens, in what order, who does it, and what the decision points are. Done well, it works for the business stakeholder who needs to validate the process and the developer who needs to understand the logic. That dual audience is exactly why the activity diagram has stayed in my toolkit for 25 years across government, utilities, and enterprise projects.
The challenge is that most people either over-complicate them or leave out detail that matters. This article is about getting one built correctly, so that it holds up under scrutiny in a workshop, a review, or a handover to a development team.
What an Activity Diagram Actually Represents
An activity diagram models the flow of actions through a process or system. It shows what happens step by step, who or what is responsible for each step, what decisions change the flow, and where the process starts and ends. It sits within the UML (Unified Modelling Language) family of diagrams, but you do not need a UML background to use it effectively in BA work. I rarely introduce it to stakeholders by that name. I call it a process flow or a workflow diagram, and I use the formal notation underneath without making a point of it.
Where an activity diagram differs from a basic flowchart is in its use of swimlanes to show responsibility, and its precise handling of concurrency and decision logic. If you are working on business process analysis, an activity diagram is usually the right level of detail for anything more complex than a three-step linear sequence.
The Core Elements You Need to Know
Before you draw a single line, you need to be clear on what each element does. Here is a breakdown of the components I use on every diagram:
- Initial node (filled black circle): This marks where the process starts. There is only ever one of these on a single process diagram.
- Activity node (rounded rectangle): This represents a single action or step. Each one should be named with a verb-noun combination, such as “Print Daily Summary” or “Validate Payment”, to make it unambiguous.
- Decision node (diamond): This is where the flow branches based on a condition. Each outgoing arrow from a decision node should carry a guard condition in square brackets, such as [Cash received] or [No cheques].
- Merge node (diamond): This is where two or more flows rejoin before continuing. It looks identical to a decision node, but the logic runs in reverse.
- Fork and join bars (thick horizontal or vertical bars): These handle parallel activities. A fork splits one flow into two or more concurrent flows. A join waits for all concurrent flows to complete before the process continues.
- Swimlane (vertical or horizontal partition): Each swimlane represents a role, system, or organisational unit. Activities sit inside the swimlane of whoever or whatever performs them.
- Final node (circle within a circle): This marks where the process ends. You can have more than one if the process has multiple valid end states.
- Control flow arrows: These connect elements and show the direction of flow. Every element must have at least one incoming and one outgoing arrow, except for the initial and final nodes.
How to Construct an Activity Diagram Step by Step
Step 1: Define the scope boundaries
Before you open any diagramming tool, agree on where the process starts and where it ends. This sounds obvious but it is the step that causes the most argument. On a local government project I worked on (Organisation A), I was modelling a payments receipting process. The finance manager wanted the diagram to start from when a customer walked in the door. The operations team wanted it to start from when cash hit the counter. Those are two different scopes, and mixing them would have created a diagram no one could validate. I agreed a clear trigger event with both parties before drawing anything: the process begins when all payments from the day are handed to the receipting officer at the end of the afternoon shift.
Step 2: List the roles and create your swimlanes
Write down every role or system that performs at least one step in the process. In the Organisation A example, the only active role in the end-of-day close-out process was the Receipting Officer. That made the swimlane straightforward. On more complex processes I have had five or six swimlanes, including system actors such as a payments platform or a reporting engine. Resist the temptation to create a swimlane for every team that touches a document. A swimlane should only exist if that actor performs an action, not merely receives information.
Step 3: Map the happy path first
Start with the most common flow from start to finish without any branching. In the Organisation A close-out process, the happy path was: print the Daily Summary of Revenue from the system, calculate totals from the morning shift and any afternoon payments, compare cash balances against the Daily Summary and adjust for the $100 float, put cash in a sealed envelope, print and sign the Shift Close report, print and sign the Banking Close report, put physical payments and close-out reports into a sealed plastic sleeve, place the sealed sleeve in the safe ready for banking. That sequence became the backbone of the diagram.
Step 4: Add decision points and alternative flows
Once the happy path is solid, layer in the decisions. In the Organisation A process, there were two: whether cheques had been received during the day, and whether cash had been received. If cheques were present, the officer calculated combined totals before moving to the cash comparison step. If there was no cash, the cash envelope step was skipped entirely. Each decision node needs guard conditions on every outgoing arrow. A diamond with an unlabelled arrow is a gap in your model.
Step 5: Validate with the people who do the work
Print the draft or share it on screen with the people who perform the process, not just their manager. This is where the friction usually appears. When I walked the Organisation A diagram through with the receipting officer, she pointed out immediately that the diagram showed the Banking Close report being printed before the Shift Close report. In practice, the Shift Close had to be signed first because the Banking Close pulled figures from it. If I had gone to sign-off without that session, the diagram would have been technically wrong and would have caused problems for the developer configuring the new system’s report sequencing.
A Comparison: Activity Diagram vs Other Process Modelling Approaches
| Approach | Best For | Handles Swimlanes? | Handles Decisions? | Handles Concurrency? | Audience Fit |
|---|---|---|---|---|---|
| Activity Diagram (UML) | Detailed process and system behaviour modelling | Yes | Yes | Yes | Business and technical |
| BPMN Process Map | Business process documentation and automation | Yes (pools/lanes) | Yes | Yes | Business and technical |
| Basic Flowchart | Simple linear processes | Sometimes | Yes | No | Business |
| Sequence Diagram (UML) | System interaction and message passing | No (lifelines) | Limited | Yes | Technical |
| Use Case Diagram | Showing what the system does at a high level | No | No | No | Business and technical |
If you are already using use cases to capture system behaviour, activity diagrams complement them well. The use case tells you what the system must do; the activity diagram shows how the flow of actions achieves it step by step.
Where Activity Diagrams Earn Their Keep and Where They Do Not
In my experience, activity diagrams are genuinely useful in three situations. First, when a process crosses multiple roles or systems and a text description would be ambiguous. Second, when a developer needs to understand conditional logic in a workflow before writing code or configuring a system. Third, when you need stakeholders to formally validate a process before you baseline your requirements. They are less useful when the process is genuinely simple and a brief narrative will do, or when the audience has no appetite for structured diagrams and will disengage the moment they see a swimlane. Knowing when not to use a tool is as important as knowing how to use it.
For your process documentation overall, a business process documentation template can help you embed the activity diagram within a broader set of artefacts so that context, scope, and assumptions are captured alongside the visual model.
Common Mistakes That Undermine the Diagram
- Unnamed decision branches: Every arrow leaving a decision diamond must have a guard condition. Without it, readers have to guess what triggers which path, and they will guess differently.
- Activities that are too broad: “Process payment” is not an activity. It is a sub-process. If a step contains multiple decisions or roles within it, it needs to be expanded into its own diagram or broken down further.
- Missing merge nodes: If two flows from a decision diamond reconnect, that join point must be shown explicitly as a merge node. Letting the arrows run back together without a symbol creates ambiguity about whether both paths must complete or just one.
- Swimlanes that represent documents, not actors: I have seen diagrams where someone created a swimlane called “Finance System” as a passive store of data. Swimlanes are for actors that perform actions. If the system triggers an action, give it a swimlane. If it just holds data, reference it in the activity label.
- No agreed start trigger: Diagrams that begin with “Start” but no context about what triggers the process are hard to validate and often capture a scope the business did not intend.
Tooling: What I Actually Use
I have built activity diagrams in Visio, Lucidchart, draw.io, and Enterprise Architect. For most BA work, draw.io is free and capable enough. If you are working in a team that uses Confluence, draw.io integrates directly. Enterprise Architect is worth the investment if you are on a large programme that needs a full UML repository, but it has a learning curve. The tool matters far less than the rigour you apply to the notation. I have seen flawless diagrams built in PowerPoint and terrible ones built in specialised modelling tools.
Whatever you choose, make sure the diagram is editable by whoever needs to maintain it after you leave the project. A PDF of a diagram no one can update becomes a liability the moment the process changes.
The activity diagram is one of those techniques that looks simple until you try to validate it with real stakeholders against a real process. The value is not in drawing the boxes and arrows. It is in the conversations that the diagram forces: who does what, what happens when things go wrong, and whether the sequence everyone assumed is actually the sequence that happens in practice. Getting that clarity onto one page, in a form that both the business and the development team can read, is the work. The diagram is just how you show it.
Frequently asked questions
What is an activity diagram in business analysis?
An activity diagram is a UML modelling tool that shows the step-by-step flow of actions through a process, including who performs each step, what decisions branch the flow, and where parallel activities occur. Business analysts use it to document and validate workflows before requirements are baselined or systems are built. It works for both business process documentation and system behaviour modelling.
What is the difference between an activity diagram and a flowchart?
A flowchart is a general-purpose diagram that shows process steps and decisions in a linear format, usually without formal notation for concurrency or role separation. An activity diagram uses UML notation, includes swimlanes to assign responsibility to specific actors or systems, and can represent parallel flows using fork and join bars. For BA work involving multiple roles or system interactions, an activity diagram is more precise and more useful.
What are the main elements of an activity diagram?
The key elements are the initial node (where the process starts), activity nodes (individual actions), decision nodes (where the flow branches), merge nodes (where branches rejoin), fork and join bars (for parallel flows), swimlanes (which assign responsibility), control flow arrows (showing direction), and a final node (where the process ends). Each element has a specific meaning and should be used consistently to avoid ambiguity.
When should a business analyst use an activity diagram?
Use an activity diagram when a process crosses multiple roles or systems, when conditional logic needs to be communicated clearly to developers, or when stakeholders need to formally validate a workflow before sign-off. It is less appropriate for very simple linear processes where a short written description would serve just as well. Choosing the right tool for the complexity of the process is part of the BA’s job.
What tools can I use to draw an activity diagram?
Common options include draw.io (free and integrates with Confluence), Lucidchart, Microsoft Visio, and Enterprise Architect for larger UML programmes. For most BA projects, draw.io provides everything you need without cost. The most important factor is that the diagram is editable by the people who will maintain it after the project is delivered.
Try Ash, Your Virtual BA
If you are working through a process right now and need help structuring an activity diagram, identifying the right swimlanes, or translating what you have modelled into clear written requirements, Ash can help you do exactly that. Ash is a virtual BA built on real business analysis methodology, so you can describe your process, talk through the decision points, and get practical guidance without starting from scratch. Try Ash Virtual BA and get your workflow documented properly.
Further reading
- 10.35 Process Modelling
- System and method and apparatus for using UML tools for defining web service bound component applications
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.