Approval Workflows When the Manager Is Away
When a manager is away, approvals stall unless someone else has explicit authority to act. The fix is a delegation rule that names a specific person, sets an expiry date, shows everyone who currently owns the decision, sends reminders before items age, and defines what happens when the delegate cannot decide. That keeps requests moving without giving anyone permanent or unlimited authority.
Name a delegate, not a role
A delegation that says 'the team lead approves' fails when two team leads assume the other is handling it. Name one person for each approval type. If that person is also away, the rule should name a second fallback, again a specific individual.
Suppose a purchase request for a new laptop sits with a manager who is traveling for two weeks. If the delegation names the operations coordinator as delegate, the request moves. If it names 'management,' it waits. The difference is not effort; it is specificity.
Set an expiry date on every delegation
Delegation should end automatically. An expiry date prevents a temporary arrangement from becoming permanent and keeps authority aligned with the person who is actually accountable. A common pattern is to set the expiry to the manager's return date plus one working day.
When the expiry passes, the system should revert the approval right to the original owner and notify both people. That notification is the test: if the original owner does not receive a message that authority has returned, the expiry is not working. Run this test once with a real request before relying on it.
Make current ownership visible
Anyone looking at a pending request should see who owns it right now, whether that is the manager or the delegate, and when the delegation ends. This removes the most common cause of delay: people waiting because they are unsure who should act.
Visibility also protects the delegate. If the request history shows that authority was delegated and for how long, the delegate can act without needing to justify the decision later. The record does the explaining.
Remind before items age, not after
A reminder that arrives after a request has already missed its deadline is an autopsy, not a nudge. Configure reminders to fire before the expected turnaround, and send them to the current owner, not only the original manager.
Keep the reminder content short: what is waiting, who owns it, and when the delegation ends. Long reminder emails get filtered out mentally. A single line with a link to the request is usually enough.
Define the exception path
Some requests will fall outside the delegate's authority, for example those above a value threshold or involving a new supplier. The workflow should route these to a named escalation contact rather than leaving them in the delegate's queue.
The exception path should also cover the case where the delegate is unreachable. If no one can decide within the expected window, the request should escalate automatically to the next named person. This is not about distrust; it is about keeping a decision from depending on one person's availability.
Keep the scope narrow
Delegation works best when it covers a defined set of approval types for a defined period. Broad, open-ended delegation creates confusion about who decided what and makes it harder to review decisions later.
Suppose a company delegates all purchasing approvals for a month. A request for office supplies and a request for a new software subscription both land with the delegate, even though only one was intended. Narrowing the delegation to routine purchases below a set value, with everything else escalating, keeps the arrangement predictable.
Continue reading
A practical next step
Explore the related Devign work, then discuss your requirements before committing to a project scope.