In a UML activity diagram, how does a flow final node differ from an activity final node?

## Two ways for a flow to stop An activity diagram is read as a token game. An **initial node** — a small filled circle — puts a token into the flow; actions pass it along; and a final node absorbs it. There are two final nodes, and the difference between them is not what they do to the token but what they do to *everything else*. An **activity final node** is drawn as a filled circle inside a hollow ring. When a token reaches it, the token is consumed **and the entire activity terminates**: every other flow still in progress anywhere in the diagram stops, wherever it happens to be. A **flow final node** is drawn as a small circle with a cross through it. When a token reaches it, that token is consumed and nothing else happens. Other flows continue exactly as they were. | | Activity final node | Flow final node | |---|---|---| | Symbol | Filled circle inside a ring | Circle with a cross through it | | Absorbs the arriving token | Yes | Yes | | Effect on other running flows | Stops all of them | None | | Typical use | The activity is genuinely over | One concurrent path has nothing more to do | | How many per diagram | Several are allowed; the first reached wins | Several are allowed and normal | ## Why the difference is invisible most of the time In a diagram where exactly one token is ever in flight — a plain sequence of actions with a few decision nodes — the two nodes behave identically. Ending the only flow and ending the whole activity are the same event, so swapping one symbol for the other changes nothing a reader could observe. That is precisely why the distinction is worth knowing rather than worth arguing about: it costs nothing until concurrency exists, and then it costs a lot. The moment a **fork node** puts tokens on two or more edges, several flows are live at once and the choice of final node becomes a real decision about behaviour. ## The worked contrast Suppose a fork node starts two concurrent paths: one sends a confirmation to the requester, the other archives the record. The archiving path is short and finishes first. - If the archiving path ends at an **activity final node**, reaching it kills the confirmation path mid-flight. The requester is never told, and nothing in the diagram looks broken — the picture is symmetric and the bug is in the choice of symbol. - If it ends at a **flow final node**, the archiving flow simply stops and the confirmation continues to its own ending. This is almost always what was meant. - If both paths must complete before anything else happens, neither final node is the answer: the paths belong in a **join node**, which waits for a token on every incoming edge before continuing. ## The trap worth remembering The sharpest failure is putting a flow final node on a path that a **join node** downstream is still waiting for. The token is absorbed, the join never receives it, and the activity deadlocks at the bar. Like the confirmation example above, it reads as tidy on the page: a path that reached a proper ending and a synchronisation point that will simply never fire. Any path feeding a join node must reach that join; if it genuinely has nothing more to contribute, the join is the wrong construct there. ## Several endings, and what they signal A diagram may carry more than one final node of either kind, and multiple activity final nodes are common where a process has distinct outcomes — approved, rejected, withdrawn. Whichever is reached first ends the activity. Before drawing three of them, ask a question about the model rather than the notation: are these genuinely different outcomes, or the same outcome reached by different routes? If it is the same outcome, one final node fed by a **merge node** reads better, because it gives every reader a single place to look for how the activity concludes. A short checklist for choosing between them: - Only one flow can ever be live? Either symbol works; prefer the activity final for the reader's benefit. - A subordinate concurrent path that ends independently? Flow final. - The whole activity is over, including any work still in flight? Activity final, deliberately. - A path a join node is waiting for? Neither — route it to the join. - Several endings that mean the same thing? Merge them and use one final node.