State Machine Workflow

Visual Flow

Rendering diagram…

When to Use This Pattern

Use a state machine when:

• The process is non-linear — items can go backwards, loop, or skip steps
• A simple "start to finish" workflow doesn't capture the real process (e.g., drafts can be rejected and revised multiple times)
• You need to enforce valid transitions — not every state can lead to every other state
• The item has a lifecycle with clear phases (Draft → Review → Approved → Published → Archived)

How It Works

Rendering diagram…

Implementation Guide

WHILE state != terminal_state:
    valid_actions = get_valid_transitions(current_state, current_user_role)
    
    display_task(item, valid_actions)
    
    chosen_action = wait_for_user_response()
    
    IF chosen_action IN valid_actions:
        execute_side_effects(current_state, chosen_action)
        current_state = transition_table[current_state][chosen_action]
        log_transition(old_state, chosen_action, new_state, user, timestamp)
    ELSE:
        reject_invalid_action()

Tips & Best Practices

• Terminal states are final. Once an item reaches Archived, Cancelled, or Completed, no transitions should be possible. This provides data integrity.
• Guard conditions. Some transitions might need additional conditions beyond role: "Can only publish if review score > 80%". Implement these as pre-transition checks.
• Timeout transitions. Combine with Escalation with SLA Timeout — if an item sits in "In Review" for 5 days, auto-transition to "Escalated".
• Version the state model. When you change the states/transitions, items already in-flight should continue with the old model. New submittals use the new model.