The problem is not leave. It is single-person dependency
Most approval workflows look fine until one person is unavailable.
A manager goes on annual leave. A director is travelling. A team lead is off sick. Someone changes roles and nobody updates the approval path. Work that normally moves in a day suddenly sits untouched because the workflow depends on one person being present, checking the right inbox, and remembering what to do next.
The visible problem is delayed approvals.
The underlying problem is that the workflow was never designed for continuity.
If an approval step only works while a specific person is available, you do not really have a workflow. You have a person acting as the workflow.
That creates risk across all sorts of operational processes:
- purchase approvals
- quote approvals
- variation approvals
- leave approvals
- invoice sign-off
- payroll exceptions
- job cost approvals
- customer credits or refunds
- contract or procurement sign-off
When these stall, the impact is rarely limited to administration. Jobs wait. Suppliers wait. customers wait. Billing waits. Teams start chasing updates manually. Then people begin working around the process just to keep things moving.
That is usually when control gets weaker, not stronger.
Delegation is a system design requirement, not an afterthought
A lot of businesses treat delegation as something informal.
Someone says, “While I’m away, just send those to Sarah.”
That might work once or twice, but it is not a reliable operating model.
A proper approval workflow needs built-in rules for what happens when the normal approver is unavailable. That means the delegation logic should exist before the exception happens, not be invented during it.
This matters for two reasons.
First, the business needs continuity. Work cannot stop because one person is absent.
Second, the business still needs control. You do not want urgency to turn into a vague free-for-all where nobody is sure who can approve what.
Good delegation design solves both.
Start by identifying where approvals create operational dependency
Before you change any software or add automation, map the approval points that depend too heavily on individuals.
Look for steps where all of the following are true:
- one named person is the only approver
- the next step cannot happen without their decision
- there is no formal backup path
- the current workaround happens through email, phone calls or chat messages
- nobody can easily see what is waiting, who owns it, or how long it has been sitting there
These are hidden bottlenecks.
A common example is quote approval. Sales prepares the quote, but anything above a certain margin threshold must be approved by one senior person. That sounds sensible. But if that person is away for three days and there is no alternate path, quotes sit idle even when the risk is low and the commercial decision is straightforward.
Another example is payroll exceptions. A supervisor may need to approve overtime, allowances or site-specific adjustments. If they are absent and there is no defined delegate, payroll staff either wait and risk delays or process it based on incomplete authority.
In both cases, the issue is not the need for approval. The issue is that the approval point has no continuity design.
Define temporary delegates and standing delegates differently
Not all delegation is the same.
A resilient workflow usually needs two separate concepts: temporary delegates and standing delegates.
Temporary delegates
A temporary delegate covers a defined absence such as:
- annual leave
- sick leave
- travel
- training
- parental leave
- short-term secondment
This delegation should have:
- a clear start date
- a clear end date
- a defined scope
- visibility to relevant staff
- system-level routing where possible
The main benefit is continuity without permanently changing the approval structure.
Standing delegates
A standing delegate is a built-in backup for an approval role, not just a one-off replacement. This is useful where an approval process is business-critical and cannot depend on someone manually setting an out-of-office handover every time.
For example, if a service manager normally approves technician-related cost variations, the system may define an operations manager as the standing backup if the service manager has not acted within a set time or is marked unavailable.
This avoids the business relying on someone remembering to set delegation every single time they step away.
The important point is that both should be explicit. If the workflow depends on staff guessing who the backup approver is, it is still fragile.
Delegate authority, not just access
One common mistake is giving someone access to click approve without defining the authority behind that approval.
That creates confusion quickly.
If a delegated approver can approve everything the original approver could, is that appropriate? If not, what are the limits? Does the delegation apply only to one team, one budget range, one business unit, or one approval type?
Without clear rules, you get one of two outcomes:
- people become hesitant and approvals still slow down
- people approve too broadly and control becomes inconsistent
Delegation should be tied to authority rules such as:
- dollar thresholds
- job type
- department
- risk level
- customer type
- contract value
- exception category
For example, a temporary delegate may be allowed to approve routine purchase orders up to $5,000, but anything above that still escalates to a more senior approver. Or a delegated quote approver may handle standard jobs, while non-standard pricing or contractual variations still require executive review.
The workflow should make those limits visible and enforceable.
Urgent approvals should not follow the same path as routine ones
Another reason approval workflows break during absences is that every item is treated the same way.
In reality, urgent approvals often need different handling from routine ones.
If a technician is on site and needs urgent approval for an additional chargeable item before work continues, that should not sit in the same queue and timing logic as a non-urgent internal purchase request.
This does not mean urgent approvals should bypass control.
It means the system should distinguish between urgency levels and route them accordingly.
A better model is usually:
- routine approvals follow the standard path with normal service expectations
- urgent approvals trigger faster escalation timing
- higher-risk urgent approvals may route to a different approval pool
- the reason for urgency is captured and visible in the record
That way, the business can move quickly where it needs to without creating a habit of informal side approvals through phone calls and messages.
If the only way to get an urgent approval done is to message someone directly, the system is not handling urgency properly.
Preserve the audit trail properly
A delegated approval is only useful if the business can still see what happened later.
That means the workflow needs an audit trail that answers basic questions clearly:
- who was the original approver
- who acted as delegate
- under what authority they approved
- when the delegation applied
- when the approval occurred
- whether the approval was routine, urgent or escalated
- what threshold or rule allowed the delegate to act
This matters for more than compliance. It also matters for operational trust.
Without that history, businesses end up arguing about questions like:
- “Was that actually approved?”
- “Did they have authority to sign off on that?”
- “Why did this go through Sarah instead of Mark?”
- “Was this approved during leave coverage or because the process changed?”
If the answer lives only in someone’s email trail or chat history, visibility is poor and the process is hard to review.
A proper audit trail keeps the decision inside the workflow, not scattered across inboxes.
Inbox-based workarounds are usually where control starts to weaken
When approval workflows fail during leave, businesses often fall back to workarounds like:
- forwarding emails
- asking someone to monitor another person’s inbox
- sending screenshots in chat
- getting verbal approval on the phone
- approving documents outside the system and updating records later
These workarounds feel practical in the moment, but they create new problems:
- approvals become invisible to others
- no one can easily see queue status
- turnaround times become hard to measure
- audit trails become incomplete
- duplicate or conflicting approvals become more likely
- the business becomes dependent on individuals communicating correctly
In other words, the workaround keeps the item moving once, but makes the system weaker overall.
If work regularly needs to leave the workflow in order to get approved, the workflow design is the problem.
Build escalation timing into the approval process
Delegation rules alone are not enough. You also need escalation timing.
Sometimes an approver is technically available but does not act. Sometimes a delegate is also unavailable. Sometimes nobody realises an item has been sitting untouched.
A resilient approval workflow should define what happens when time thresholds are missed.
For example:
- An approval is assigned to the primary approver.
- If no action occurs within a defined period, it is reassigned or escalated.
- If it is marked urgent, the escalation timer is shorter.
- If the delegated approver also does not act, the item moves to the next authority level.
- The workflow records each reassignment or escalation step.
This matters because many approval delays are not caused by rejection. They are caused by silence.
The system should not require someone from operations, finance or administration to manually chase every stalled item just to discover where it is stuck.
Review threshold and role logic regularly
Approval workflows often outlive the structure they were built for.
A business grows. Teams change. Responsibilities shift. New managers come in. Approval thresholds that made sense two years ago become either too restrictive or too loose.
That is why delegation design has to sit alongside regular review of approval logic.
Questions worth checking include:
- Are approvals tied to specific people when they should be tied to roles?
- Are the threshold limits still appropriate?
- Are too many low-risk items requiring senior approval?
- Do delegates have the right authority range?
- Are there approval steps that no longer add meaningful control?
- Are urgent and routine approvals still separated properly?
- Does the escalation path still reflect the real organisational structure?
If these rules are not reviewed, the workflow slowly drifts away from how the business actually operates.
That usually leads to two outcomes: either too much gets blocked unnecessarily, or people stop respecting the process and start bypassing it.
Role-based design is usually more resilient than person-based design
Where possible, approvals should be designed around roles and rules, not just named individuals.
That does not mean every approver becomes generic. It means the logic should reflect the operating structure of the business.
For example:
- quotes over a threshold go to the sales manager role
- operational cost variations go to the service manager role
- purchases above a higher threshold go to the general manager role
- if the role holder is unavailable, the standing delegate or escalation role is used
This is more resilient than hard-coding every step to a specific person.
People go on leave. People resign. People cover other teams. People move between business units. A workflow built around roles can adapt much more cleanly, especially when paired with temporary delegation settings and standing backups.
What a well-designed approval continuity model looks like
A practical approval continuity model usually includes the following:
- approval points are clearly identified
- approval authority is based on role and threshold, not only person
- temporary delegates can be assigned with dates and scope
- standing delegates exist for critical approvals
- urgent items follow different timing and escalation rules
- approval actions stay inside the system of record
- audit trails show who approved, when, and under what authority
- escalation occurs automatically when action is overdue
- role and threshold logic is reviewed periodically
- inbox or verbal workarounds are the exception, not the real process
This does not have to be overly complex.
In many businesses, the improvement is not about adding more software. It is about deciding the rules properly and then making sure the workflow actually enforces them.
A simple test for whether your approval workflow is resilient
If one key approver went on leave tomorrow, could the business answer these questions immediately?
- What approvals would stall?
- Who is authorised to act in their place?
- For how long?
- Up to what threshold?
- Which approvals still require escalation?
- Where would staff see the current status?
- Would the audit trail still be intact?
If the answer to those questions depends on checking emails, calling around, or relying on what people think the rule probably is, the workflow is still too dependent on individuals.
That dependency does not show up when everything is normal.
It shows up when someone is unavailable and the business realises the process had no continuity built into it.
Build the continuity rules before you need them
Approval workflows do not fail during leave because leave is unusual. They fail because unavailability was treated as an exception the system did not need to handle.
In practice, absences are normal. So are sick days, travel, role changes and delayed responses. A workflow that cannot absorb those conditions is not finished.
The fix is not to remove control. It is to design control so it still works when the usual approver is not there.
That means defining delegates clearly, separating urgent from routine approvals, preserving audit trails, setting escalation timing, and reviewing approval authority as the business changes.
If your approvals currently rely on inbox forwarding, verbal handovers or someone remembering to “keep an eye on things”, the workflow probably needs redesign.
Where approvals span multiple roles, systems and exception paths, mapping the logic properly before changing the tooling is usually the most useful first step. That is the kind of workflow design work 5M Consulting helps businesses sort out.