State machine diagram examples
Three state machines you could copy today - an order lifecycle, an editorial workflow that loops backwards, and the fragment that shows why a waiting state is not a stuck one.
8 min readUML 2.5.116 of 35
01Example 1: an order lifecycle
If a table in your database has a status column, this diagram is already implicit in the codebase - it is just written across a dozen guard clauses instead of drawn once. Making it explicit is the cheapest defect-finding exercise a state machine offers.
Read the transitions rather than the boxes. Each is labelled with the trigger that causes it - checkout, pay, dispatch, deliver - and one carries an effect after a slash: dispatch / print label. Those labels are the content. A diagram of six rounded boxes with unlabelled arrows says only that things change, which everybody already knew.
The two final states are deliberate. Cancelled and delivered are both terminal and they are not the same outcome, and drawing one ringed disc for both would say the order ended without saying how. Nothing in UML limits you to one.
02Example 2: a workflow that loops backwards
Real workflows rarely run in one direction. Something gets rejected, goes back, and comes round again - and the backwards transition is usually where the interesting rules live.
The revise transition from Rejected to Draftis what makes this a state machine rather than a checklist. It says a rejected article is not finished - it re-enters the same cycle, and any counter such as “rejected twice means escalate” hangs off that arrow rather than off a state.
Note that Rejected has an exit and Published does not. A state with no outgoing transition and no final state after it is a claim that the object stays there forever, which is occasionally true and more often an omission. Checking every leaf state for that is a two-minute review that finds real gaps.
The trigger names are events in the domain vocabulary - submit, approve, reject, revise - not method names. That keeps the diagram readable by the editors who own the process, which is the audience that can tell you it is wrong.
03Example 3: two exits that are not a decision
The most common confusion when someone moves from activity diagrams to state machines is what two arrows out of one box mean.
These are two triggers, not two branches of a decision. The order sits in Awaiting payment indefinitely; whichever event arrives first - pay or the time event timeout(72h) - decides where it goes. Nothing has to be exhaustive and there is no [else], because waiting is a legitimate outcome.
That is the opposite of an activity diagram, where a token arriving at a decision with no enabled guard is a stalled process. Same-looking geometry, opposite semantics - which is why the choice between the two notations is worth making on purpose rather than by habit.
04When to draw one at all
A state machine is cheap to draw and expensive to keep, so the question of whether the object has a lifecycle is worth asking before the first box.
Reach for it when
- The object has a status field with more than two values and rules about legal changes.
- Some transitions are forbidden and the prohibition matters - refunds, cancellations, approvals.
- The same object is touched by several services and they disagree about what it can do next.
- Timeouts or expiries change the object without anybody acting on it.
Reach for something else when
- A process crossing several objects and roles - that is an activity diagram.
- A class whose status is derived from other fields rather than stored.
- A workflow engine's own configuration, which is already a state machine written down.
- One diagram covering two objects. Draw one machine per lifecycle.
If the process spans several participants rather than one object's life, you want an activity diagram or, for a business audience, BPMN. The test is simple: if you cannot name the single thing whose states these are, it is not a state machine.
05What to remember
In one line each
- 01The transition labels are the content. Unlabelled arrows between states say nothing.
- 02Several final states are normal - cancelled and delivered are both terminal and not the same.
- 03The missing arrows are where the bugs are. Check every pair you did not draw.
- 04Two arrows out of a state are two triggers, not two branches. Nothing needs an [else].
- 05One state machine per object with a real lifecycle. A process spanning roles is an activity diagram.
06Common questions
What is a good example of a state machine diagram?
An order lifecycle: cart, placed, paid, shipped, delivered, with a cancelled branch off placed. It has six states, one trigger per transition and two different endings, which covers everything the notation is normally asked to do.
Can a state machine diagram have more than one final state?
Yes, and it usually should. A cancelled order and a delivered order are both finished but they are not the same outcome, and routing both into one ringed disc hides the distinction. UML places no limit on the number of final states.
How do you model a timeout in a state machine diagram?
As a transition whose trigger is a time event, written like timeout(72h) or after(72 hours). It leaves the state the object is waiting in and points at whatever the expiry produces. No guard is needed - the passage of time is the trigger.
What happens if no transition out of a state is enabled?
Nothing, and that is correct. A state machine waits in its current state until a trigger arrives, so a state with no enabled transition is idle rather than broken. This is the opposite of an activity diagram, where a token with nowhere to go is a stalled process.
Should there be one state machine per class?
At most one, and only for the classes that have a real lifecycle. If a class has a status column with more than two values and rules about which change is legal, draw it. If its status is derived or only ever set once, a state machine adds nothing.
Related reading