What Happens to Approvals When the Manager Is Away?

Imagine a commercial cleaning company handling this situation. A replacement machine is needed this week, but the only person allowed to approve it is on leave.

Staff either wait or improvise. This hypothetical scenario is worth considering because the mistake can look like an isolated oversight. Following the information usually reveals a repeatable weakness that better process design could address before anyone recommends new software. Understanding the distinction helps the business consider a proportionate change.

The workflow names an individual without defining a temporary delegate, spending limits or the dates their authority applies.

A temporary delegate needs a defined boundary. The system should make it easy to see when a decision was made under delegated authority rather than ordinary responsibility.

A delegation record should say which decisions it covers, not just who is covering the manager's inbox. Requests beyond that authority need a visible route to another authorised person. This prevents a sensible leave arrangement from quietly becoming a wider permanent permission. The record may look complete while still leaving a business question unanswered. That encourages workarounds: a private note, another spreadsheet or a message to a trusted colleague. Each workaround helps locally but can make the overall process harder to follow.

Record a time-limited delegate for the relevant approval type. Preserve the original request and show who made the decision under which delegation.

Each transition should identify the information required and the person authorised to make the decision. Where a connection is needed, investigate the precise actions it supports instead of assuming every status can be transferred. Keep exceptions visible with a reason and a named person responsible for resolving them. The current application may already support suitable forms, approval stages or linked tasks. The useful boundary is between preparing the next action and authorising a consequential commitment. Changing the workflow should preserve meaningful history rather than simply replacing yesterday's value. Begin with an agreed sequence of business states rather than a chain of emails.

A reminder cannot grant authority, and delegation should not automatically expose unrelated financial information.

For background relevant to approval delegation, see The Business Process That Only One Employee Understands. The issue here is the narrower workflow described in this example.

Submit a request before, during and after the leave period, including one outside the delegate's limit. Compare the proposed result with the original source and the business's intended next action. A record arriving in the right application is not sufficient if its meaning changed on the way. Staff should be able to explain both what happened and what remains to do.

For approval delegation, review the proposed outcome with the staff responsible. The test should show who owns the next action, what evidence supports the current state and which decision remains outstanding. Check that a correction leaves the history understandable and does not silently authorise a later step. Give unresolved cases a named owner and a sensible review point. A clearer process in the current tools may be sufficient; custom development needs a specific remaining problem to justify it.

Software Logic approaches workflow automation by examining the actual handover, the information involved and whether a modest improvement would be sufficient. Which decisions would stop tomorrow if your usual approver could not be reached?