How to Design a Multi-Step Leave Approval Workflow
A checklist for HR admins designing multi-step leave approvals: when a second approver helps, sequential vs simultaneous routing, scoped approvers, and what to never gate.

The single-approver leave model breaks in three places. The manager goes on vacation and nobody can approve. The team is large enough that one person cannot judge every request fairly. Or the request itself touches more than one team, and a single approver does not have the context to say yes. The usual reaction is to add a second approver to the chain. The usual mistake is to add them everywhere, which turns a 2-day approval into a 9-day one.
A good multi-step approval design adds layers only where they help and keeps the path short everywhere else. This checklist is for the HR admin or operations lead deciding which requests need a second approver, who that approver should be, and how to handle the cases where the chain would otherwise stall.
When a second approver helps
Adding a second approver is worth it in three scenarios. Outside of these, the single-manager chain is usually faster and just as reliable.
- Long absences. A request over 10 working days affects the team more than a short one and often needs awareness from a department head or HR.
- Senior or specialised roles. The only person with vendor access, the only signing authority, the named lead on a launching client. A second approver here is not bureaucracy; it is risk management.
- Cross-team coverage. When a designer is shared across product and marketing, the second team has a legitimate stake in their availability.
For every other case (short requests, common team members, routine vacation windows), a single approver is faster and produces the same outcome.
Sequential vs simultaneous approval
Two routing patterns dominate. Each suits a different decision shape.
| Pattern | How it works | Best for |
|---|---|---|
| Sequential | Approver A acts first; only after approval does Approver B receive the request | Hierarchical decisions where the first approver acts as a filter |
| Simultaneous | All approvers receive the request together; final decision when all (or a quorum) respond | Peer decisions where multiple teams have equal stake |
Sequential is the right default for most companies: the line manager approves first, then HR or a department head approves long absences. Simultaneous is better when approvers are peers, for example when a request affects three teams and any single veto is enough to block it. The cost of simultaneous is more notifications going out; the benefit is parallel response, which can cut decision time in half.
Voting groups: when a quorum is enough
A useful third pattern is voting. Instead of requiring every approver to act, the rule requires N out of M. Two out of three product leads can approve a request from a shared designer. Three out of five partners must agree for a partner-level absence at a law firm.
Voting works when:
- The approver group is genuinely peer-level.
- Any quorum-sized subset has enough context to decide.
- The remaining approvers can be informed even if they did not act.
Voting does not work when one of the approvers has unique veto power (the head of finance for budget-affecting decisions, the safety officer for compliance leave). In those cases, a hard requirement for that approver is better than a quorum.
Scoped approvers: keep the chain local
A common mistake is making a single HR approver handle the second step for the entire company. If the company is in three countries, the regional context matters: Swedish public holidays, Croatian probation rules, Serbian labour codes. A scoped approver model gives each region its own HR approver for the second step.
Scoped approvers are useful for:
- Country-specific second-step. The HR person in the requester's country approves long absences, not a central HR lead.
- Department-specific approvers. Engineering long absences flow through the VP of engineering; sales long absences flow through the head of sales.
- Reporting-team approvers. When an employee reports into a project team different from their HR team, the approval can route to either depending on the leave type.
The full configuration is on the multi-approval page. Scoping is what keeps the chain short even as the company grows.
What never to gate
Three request types should not require multi-step approval. Adding extra steps here slows down decisions that have to be fast.
- Sick days. A sick day is a notification, not a request. Multi-step approval here is counterproductive and in many jurisdictions creates legal risk.
- Bereavement leave. If the company offers it, the employee should be able to apply it without waiting for two layers of approval.
- Emergency leave. Same principle: the manager should be informed, not gated as a precondition.
These leave types should route to a single approver for awareness and balance accuracy, not as a hurdle. The notification is the point; the click is a formality.
Handling the "approver on vacation" problem
The single biggest failure mode of multi-step approval is the approver themselves being on leave. The request sits, the requester is unsure if it was received, and HR ends up resolving by hand. Three fixes prevent this:
- Designate a delegate. Every approver names a backup. When the approver is on approved leave, requests route to the backup automatically.
- Time-bound escalation. If an approval is pending for more than 3 working days, the request escalates to the next-step approver or HR.
- Visible status. The requester sees who the current approver is and when they last acted. Silence is the worst part of waiting.
The delegate pattern is the most reliable. Combined with escalation as a safety net, it covers nearly every case where an approver is unreachable.
Designing the chain: a step-by-step checklist
Run this in order when setting up multi-step approvals for the first time.
- Map the current org chart. Each employee should have exactly one line manager. If two managers share an employee, write down which one approves leave.
- Decide which leave types need multi-step. Long vacation usually yes; short vacation usually no; sick days never.
- Define the threshold for "long". A 10-day rule is common. Five and 15 are also defensible. Pick one and document it.
- Choose the routing pattern. Sequential for hierarchical decisions, simultaneous for peer decisions, voting for true peer groups.
- Set the second-step approver. Department head, HR, or scoped per country.
- Configure delegates and escalation. Every approver names a backup; escalate after 3 working days of inactivity.
- Run two test requests. One short request that should auto-route to a single approver. One long request that should route to two. Confirm the notifications, the balance update, and the calendar update for each.
The product side of these settings is on the multi-approval feature page with screenshots of the rule configuration.

Common chain designs by company size
Different company sizes settle into different patterns. None is universally right; these are starting points, not prescriptions.
| Company size | Typical chain | Why |
|---|---|---|
| Under 25 | Single approver, founder or HR | Decisions are fast and context is shared |
| 25 to 100 | Line manager for short requests, line manager plus HR for long | Balances speed with policy enforcement |
| 100 to 500 | Line manager, department head for long, scoped HR for country-specific | Local context matters; central HR cannot judge every case |
| 500+ | Scoped per country, sequential with delegates and escalation | Reliability and audit trail matter more than speed |
The single multi-step pattern that holds across sizes is "single approver as the default, second approver as the exception". Companies that flip this rule end up with HR as a permanent bottleneck.
Approval messages: what the requester sees
The chain is only useful if the requester knows where their request is. Three messages keep the chain transparent.
- On submission: "Submitted to [Approver A]."
- On first approval: "Approved by [Approver A]. Forwarded to [Approver B]."
- On final approval or rejection: "Approved." or "Rejected by [Approver B] with reason."
Silence between steps is the most common complaint. A short status line removes it. For requests that escalate due to inactivity, a fourth message is useful: "No response within 3 days. Escalated to [HR]."
For the broader case for multi-person approval and why a single approver is risky, the multi-person approval article covers the failure modes in detail. The auto-approval article covers the other half of the chain: which requests should skip approvers entirely.
What to review after three months
After the chain runs for a quarter, three numbers tell you whether it is working.
- Median approval time. If it is over 2 working days for short requests, the chain is too long. Trim it.
- Escalation rate. If more than 10 percent of long requests escalate, your approvers are overloaded; rebalance or expand the delegate list.
- Rejection rate by step. If second-step approvers rarely reject, they may not be adding value. Consider dropping the step for the cases they rubber-stamp.
The point of multi-step approval is to add a layer where judgment matters and remove it where it does not. Reviewing these numbers quarterly keeps the design honest.
To build the approval chain end-to-end with delegates, escalation, and scoped approvers, the multi-approval page walks through the configuration with screenshots, and the vacation rules engine page covers how approval interacts with accrual, blackout, and probation rules.

