Multi-step approval workflow
Submission, review, approval, rejection, and completion states.
Every organization runs on approvals: purchase requests, leave, contract reviews, design changes, hiring decisions. Yet most teams track them in spreadsheets or email chains instead of explicit workflows. This template models the lifecycle: a request starts as a draft, gets submitted, reviewed, approved or rejected, and finally executed. Rejections loop back to draft so the requester can revise.
The state view clarifies a crucial insight: at any moment, a request is in exactly one state. That state determines what actions are allowed (a request cannot be approved twice; a completed request cannot be reopened). The diagram makes these constraints visible.
When to use this template
- Process documentation — define who can make what transitions and what information is required at each state.
- Software implementation — build your approval system to mirror this diagram, ensuring state transitions are enforced (you cannot approve a Draft request; you cannot move a Completed request back to Submitted).
- SLA tracking — annotate each state with a time limit (Draft: 7 days, In Review: 2 days) to make it clear when escalation or timeout triggers.
How to adapt it
Customize states and transitions for your domain:
- Parallel approval paths — add multiple In Review states: Manager Review, Finance Review, Legal Review. Chain them or run them in parallel depending on your rules.
- Conditional routing — requests over a threshold go through Executive Review; smaller amounts skip to Approved. Model this with a decision outside the state machine or add explicit high-threshold and low-threshold states.
- Expiration and escalation — In Review can transition to Timed Out if no reviewer responds within 2 days. Timed Out escalates to a manager. Add these transitions to your diagram.
Visual edits regenerate clean code, so you can experiment with state structures without Mermaid syntax complexity.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
stateDiagram-v2
[*] --> Draft
Draft --> Submitted: Submit for review
Submitted --> In Review: Reviewer assigned
In Review --> Approved: Reviewer approves
In Review --> Rejected: Reviewer rejects
Rejected --> Draft: Resubmit
Approved --> Completed: Execute action
Completed --> [*]
Frequently asked questions
- What is a state diagram for approval workflows?
- It models the lifecycle of a request — draft, submitted, in review, approved, rejected, completed — and the transitions between them. Unlike a flowchart, a state diagram emphasizes that a request IS in a state at any moment, making it ideal for documenting how a system tracks and enforces state transitions.
- Why does a rejected request go back to Draft instead of Submitted?
- Because the requester needs to make changes (rewrite the request, add missing info) before resubmitting. The Draft state gives them a safe workspace. Direct resubmission would skip the editing step. However, your process might differ — you can customize the transition.
- How do I model multi-level approval (manager, director, executive)?
- Add more In Review states with different names: In Manager Review → In Director Review → In Executive Review. Chain the transitions: each reviewer approves to the next level, or rejects back to Draft. Visual edits regenerate clean code.
- What happens if a reviewer takes too long or an approval expires?
- Add a timeout transition: In Review → Timed Out, then either auto-reject or escalate to a manager. This makes SLA enforcement explicit. Model the escalation as: Timed Out → Escalated → In Executive Review.