Delegated approvals in workflows: vacation mode and substitutes

Why approvals get stuck when people are away

Approvals stall for a simple reason: the workflow is waiting on one specific person, and the system doesn’t know what to do when that person is offline. A request hits their inbox, nobody else has authority to act, and everything stops.

This gets worse when approvals are tied to a name instead of a role. Teams change, people go on leave, managers travel. If the workflow can’t automatically switch to a substitute, you end up with “urgent” pings, manual workarounds, and late decisions.

It also helps to separate a few similar actions people often mix up:

• Delegation: the original approver keeps responsibility, but a substitute can act on their behalf for a period or specific cases.
• Forwarding: the task is shared or sent to someone else, but the system may still expect the original person to respond.
• Reassignment: ownership of the approval task moves to another person, often permanently or for a single request.

The real goal isn’t just speed. It’s predictability and a clean record.

“Transparent” means two things for managers and auditors: you can see why the workflow routed to a substitute, and you can prove who approved, when, and under what rule. If Alex is on vacation and Priya approves a purchase, the history should show that Priya acted as Alex’s delegate. It shouldn’t look like Alex approved, and it shouldn’t vanish into a private chat.

The target outcome is simple: no blocked requests, and a clear, reviewable trail of who did what, even when someone is away.

Key terms: approver, substitute, and delegation

Clear words prevent messy rules later. If people don’t agree on who can approve what, your workflow will either stall or create audit headaches.

Most approval workflows have a few common roles:

• The requester starts the process (expense, purchase request, access request).
• The approver makes the decision.
• An admin configures the workflow, permissions, and rules.
• A substitute (sometimes called a delegate) is allowed to approve on another person’s behalf.

A primary approver is the default person expected to approve a step. A backup approver is the fallback person who can approve when the primary can’t.

People often mix up “backup approver” with “second approver,” but they’re different. A second approver adds an extra level. A backup is an alternate path for the same level.

Delegation is the rule that lets a substitute act. The two common styles are:

• Always-on delegation: the substitute can approve anytime, even if the primary approver is available.
• Absence-only delegation: the substitute can approve only when the primary approver is marked away (vacation mode) or a timeout is reached.

Approval levels are the ordered steps a request must pass (manager, then finance, then legal, then IT, depending on the request and amount). Keep “levels” separate from “substitutes”: levels define what must be approved; substitutes define who can approve when the usual person can’t.

Pick the delegation model that fits your process

Not every team needs the same backup approach. The right model depends on how often people are away, how risky the decision is, and how predictable your approval steps are.

Pick one primary model first and treat the rest as exceptions. Mixing everything from day one confuses users and makes audits harder.

Common delegation models (and when they work)

Most teams end up using a combination of these:

• Vacation mode (date-based): the approver sets a start and end date, and requests route to a named substitute during that window.
• Manual one-off delegation: an admin or manager assigns a substitute for a single request when an emergency happens.
• Rule-based delegation: the substitute is chosen by rules like team, request category, or amount.
• Escalation: if nobody responds in time, the request moves to the next person (often the approver’s manager or an on-call queue).
• Separation of duties: sensitive approvals require a different person (or a second approver) so the requester or substitute can’t approve their own work.

Vacation mode is usually the easiest day to day. Rule-based delegation works well for larger teams because it reduces manual decisions about coverage. Escalation isn’t a replacement for delegation. It’s a safety net for timeouts.

Questions that decide the model quickly

A few answers will narrow your options fast:

• Is the approval high-risk (money, access, compliance) or low-risk (routine admin)?
• Do you need one substitute per person, or a pool (like “Finance On-Call”)?
• Should the substitute be visible to the requester, or only to admins?
• How long can requests wait before escalation triggers?
• Do you need hard rules that block self-approval?

Design rules for vacation mode and substitutes

Vacation mode only works when it’s predictable. The goal is simple: approvals keep moving, and everyone can see who’s responsible.

Require a clear time window. Every delegation should have a start and end date (and a time zone if you work across regions). Avoid “until further notice.” If someone forgets to turn it off, approvals can route to the wrong person for weeks.

Decide who can choose the substitute. Self-chosen delegation can work in small teams, but it can be risky if people pick someone who isn’t trained. Manager-assigned fits most org charts. Admin-assigned is best when you need strict control, but it can slow setup.

Set eligibility rules the system can enforce. Keep them simple, and don’t allow “special cases” that only exist in someone’s head. Typical rules include being in the same department or cost center, having the right approval level, and completing required training. Always block obvious conflicts: the substitute shouldn’t be the requester, and you should prevent circular approvals.

Define what happens to in-flight approvals. Many teams route new requests to the substitute but keep existing pending items with the primary approver unless they’re overdue. Once overdue, the workflow can auto-reassign or escalate.

Make the status visible. The requester should see the current approver, whether delegation is active, and what’s next. A status like “Waiting for approval (delegated to Alex until Jan 30)” cuts follow-ups and keeps trust high.

Step-by-step: implement alternate approvers in a workflow

Start by writing down the exact approval path for one common request (purchase, access, policy exception). Keep it small. Two to four steps is enough to design the pattern.

A practical implementation pattern

1. Map each step to a role and a single owner of record. Even if a substitute can act, keep one primary approver per step so responsibility stays clear.

2. Choose one primary trigger for delegation. Most teams use an absence flag, a date window, or a manager-controlled switch. Pick one first so people aren’t surprised by silent reroutes.

3. Add routing rules to choose the acting approver. A predictable order is easiest to explain later: user’s chosen substitute, then manager, then a shared backup queue. Decide whether the substitute can approve immediately or only after a timeout.

4. Set expectations with notifications. Requesters should see who is responsible right now. Primary approvers should be told delegation is active and how to turn it off. Substitutes should get the context and a clear way to decline if they shouldn’t act.

5. Run one end-to-end test and inspect the history. You should be able to see who was assigned, why delegation happened, who approved, and when.

Test and confirm

Use a realistic scenario: the primary approver is “on vacation” and the substitute approves. Then repeat with the substitute unavailable to confirm your fallback rule. Finally, confirm the audit trail shows both the primary and the acting approver, plus the delegation reason, so an auditor can understand the handoff without asking anyone.

What to log for a clear approval history (audit trail)

An audit trail should answer three questions without guesswork: what happened, who did it, and why it was allowed. This matters even more with delegated approvals, because the “responsible approver” and the “person who clicked” may be different.

Log delegation rules as first-class records, not settings that silently change. Capture who delegated to whom, the start and end time, the scope (which requests, amounts, teams, or document types), and who approved or confirmed the change if your process requires sign-off.

Approval decisions should be immutable events. Don’t overwrite “pending” with “approved.” Record events like “Approved,” “Rejected,” or “Requested changes” and keep them, even if the workflow restarts.

A practical audit trail usually includes:

• Event ID, workflow item ID, and step name
• Timestamp (with time zone), actor identity, and their role at the time
• Acting-on-behalf-of details (original approver, delegation rule ID)
• Outcome plus comment, reason code, and any attachments
• Any edits to delegation rules (who changed what, and when)

Keep comments and attachments tied to the decision event. If they live in a separate chat or a generic “notes” field, it becomes hard to prove which comment supported which decision.

Finally, make the history readable. A single timeline that shows delegation changes, notifications sent, decisions made, and escalations in order prevents disputes later.

Transparency: what users should see while approvals happen

People accept delays when they can see what’s happening. When they can’t, they chase the wrong person, resend requests, or assume the system is broken.

Requesters and reviewers should always see the current approver and the reason they were chosen. If the task moved from the primary approver to a substitute, show it directly: “Assigned to: Priya (substitute for Alex).” That one line prevents confusion and protects accountability.

Also show the delegation window and who set it. “Delegation active: Jan 10 to Jan 20, set by Alex” helps teams trust the handoff is intentional.

Hidden reassignment is where audits get messy. If someone can swap approvers without leaving a visible trace, users lose confidence and managers can’t tell who made the call. Make reassignment visible to the right people, and always record who triggered it.

A simple “View history” panel is usually enough. Keep it focused: current status, current approver and why, delegation period, any manual reassignment, and decision comments.

Privacy matters too. Define what each role can see. A requester may need names and status, while HR, finance, or legal workflows may require masking internal notes.

Common mistakes that cause delays or audit problems

Delegation usually fails for simple reasons: rules are too loose, records are too vague, or there’s no backup plan. The result is predictable: requests sit in limbo, and later nobody can prove who approved what.

A common trap is allowing delegation to someone who can’t approve that type of request. For example, a buyer delegates purchase approvals to a teammate who doesn’t have the spend limit. The substitute clicks approve, finance flags it, and now you have to unwind the transaction and explain why the system allowed it.

Mistakes that show up often:

• Delegation to self, or to an unqualified person (wrong role, wrong limits, conflict of interest)
• Delegation with no end date
• Overwriting the original approver on the record (you lose the chain of responsibility)
• No escalation path when both primary and substitute are unavailable
• Too many notifications, so people mute them and miss the one that matters

Notification overload is subtle. If every step triggers email, chat, push, and reminders, users learn to ignore everything.

Design choices that prevent most problems:

• Require start and end dates for delegation, with automatic expiry
• Validate substitutes against clear rules before activation
• Keep both identities: “assigned approver” and “acted by,” and never erase the original
• Add escalation: if no action in X hours, route to a manager or an on-call queue

Quick checklist before you roll it out

Delegation works when the “boring details” are consistent. Before you enable vacation mode for the whole company, scan every approval step and ask: if the assigned approver is unavailable today, what happens next?

• Every step has a named backup (or a defined on-call queue), and that backup has the right permissions.
• Delegation rules are time-bound, and admins can see which delegations are active.
• The approval history shows both people: who was responsible and who acted.
• For any record, you can answer “who approved, when, and under what rule” without guessing.
• There’s an escalation for timeouts (for example, after 48 hours, reassign to a manager or a queue).

Then test at least one “person on vacation” scenario end to end: request submitted before the vacation starts, approved during the vacation, and reviewed after the person returns.

Example: a realistic approval handoff during a vacation

A sales team submits a purchase request for 12 new headsets (USD 1,200). The request normally goes to Maya, the Sales Manager. But Maya is on leave for two weeks, and approvals can’t wait.

Before leaving, Maya enables vacation mode and names Jordan (Sales Ops Lead) as her substitute for purchase approvals up to USD 5,000. Anything above that still goes to Finance.

Here’s how the handoff plays out in a clean, audit-friendly way:

• Mon 9:10: A rep submits “Headsets for onboarding” with vendor and cost center.
• Mon 9:10: The workflow assigns the step to Maya, then immediately reroutes to Jordan because vacation mode is active.
• Mon 9:18: Jordan reviews the request and approves. The record shows “Jordan (acting for Maya)” and includes Jordan’s note: “Approved for Q1 onboarding. Budget confirmed.”
• Mon 9:18: The workflow continues to Finance for a budget check, then marks the request as approved.

Two details make this feel trustworthy. The requester can see why the approver changed (“Routed to substitute: Maya out of office”), and Maya isn’t left guessing when she returns.

When Maya comes back, she opens an “Approvals during absence” view and reviews what Jordan approved on her behalf. She can filter by date range, amount, or requester. She doesn’t re-approve anything, but she can flag a request for follow-up if something looks off.

Later, an auditor asks, “Who approved this purchase, and why wasn’t it Maya?” The timeline tells one consistent story: original approver, delegation reason (vacation mode), substitute identity, acting-for attribution, timestamped decision, and the note.

Next steps: roll out safely and keep it easy to maintain

Treat delegation like a small product change, not a checkbox. The goal stays the same: approvals keep moving when people are away, and you can explain every decision later.

Start with one workflow that hurts when it stalls (expenses, purchase approvals, or access requests). Keep the scope tight: one team, one approval path, and one clear success measure, like “no approvals waiting longer than 24 hours because someone is out.”

Write a short delegation policy people will actually follow: who can delegate, what can be delegated (for example, only below a cost or risk limit), how delegation starts and ends, and what an emergency override looks like and how it gets recorded.

Assign one owner for roles and rules, and set a recurring review (monthly or quarterly) to clean up outdated substitutes. Most long-term issues come from stale delegations that were never turned off.

If you want to build an approval app without heavy coding, AppMaster (appmaster.io) can model users, roles, and delegation windows in a database, then implement routing and timeouts in a visual Business Process Editor while keeping a consistent approval history for audits.

Roll out in phases, listen for confusion, and expand to the next workflow only after the first one runs smoothly for a few weeks.