An activity diagram is the UML diagram for modeling a workflow or process as a flow of actions. It shows the steps in order, the decisions that branch the flow, and the forks and joins where work runs in parallel, often grouped into swimlanes by who performs each step. Developers and analysts use it to model business processes, use-case flows, and the logic inside a system.

An activity diagram uses a filled circle for the start node, rounded rectangles for actions, a diamond for a decision (with a guard on each path), a thick bar for a fork or join, a diamond for a merge, arrows for control flow, and a bordered circle for the end node. Swimlanes, or partitions, group actions by actor. This template includes a legend for each one.

They look related but mean opposite things. A decision is a branch: the flow takes one path out of several, chosen by a guard condition like [in stock]. A fork is parallel: the flow splits and all the outgoing paths run at the same time, later rejoined by a join. Use a decision for 'either or', and a fork for 'both at once', like packing an order while payment processes.

Both show a process as a flow of steps, but an activity diagram does more. As part of UML, it adds forks and joins for parallel work, swimlanes that show who performs each step, and guarded decisions. A flowchart is simpler and sequential, fine for a straightforward procedure. Reach for an activity diagram when a process runs concurrent paths or crosses several actors.

This template's board is one: order fulfillment. After a customer places an order, an 'In stock?' decision branches to either notifying the customer or processing the order. A fork then runs packing and payment in parallel, a join waits for both, and the order ships before the flow reaches the end node. The swimlanes show Customer, Sales, and Warehouse each owning their steps.