Classify why the approval cannot proceed
An approval can stall because the approver is on planned leave, the account has been disabled, the workload is excessive, required information is missing, or the request exceeds the person's authority. These conditions should not trigger the same fallback. Planned leave is suited to scheduled delegation. A disabled account needs immediate administrative routing. Missing information should return the request for correction. A request above a financial, security, or compliance threshold must move to someone with the right authority, not simply to whoever is available.
Model these conditions as explicit states such as pending approval, paused for information, delegated, escalated, timed out, and no eligible approver. A workflow with only pending and completed states hides operational failures inside an apparently normal queue. Every transition should preserve the reason, policy version, original assignee, acting approver, timestamps, and system or person that initiated the change. That history is essential when an auditor or process owner later asks why a decision followed a different path.
- Predictable absence: Use a prearranged delegate with effective start and end times.
- Unexpected short absence: Send reminders first, then route to an eligible backup according to urgency.
- Insufficient authority: Escalate to the appropriate authorization level rather than treating it as ordinary delegation.
- Incomplete information: Pause the business clock and request corrections instead of pressuring an approver to decide.
Constrain delegation by scope, authority, and conflicts
Delegation should not clone every permission held by the original approver. At minimum, define the applicable workflow types, organizational scope, value or risk limits, validity period, and permitted actions. A delegate might approve routine purchasing while enhanced supplier reviews still go to compliance. The delegate might be allowed to request more information but not edit the request. Keep these constraints in versioned policy data instead of scattering them across workflow scripts, integration jobs, and user-interface conditions.
Eligibility must be checked again when the action is performed, not only when the delegation is created. A delegate may have changed departments, left the company, lost a required role, or become the requester. If the same person can submit, act as delegate, and provide final approval, the workflow may finish technically while violating separation of duties. Preserve conflict rules and route cases with no eligible delegate to an exception queue. A process owner can then assign a qualified reviewer without the system silently relaxing controls.
Use a business clock, not a simple countdown
Timeouts should reflect risk and operating cadence. Emergency service restoration may need an hourly clock, routine procurement may use business days, and legal review may need a longer window. The timer should account for holidays, regional time zones, nonworking hours, requests waiting for additional information, external service outages, and formally paused cases. Otherwise, a request submitted late on Friday can appear overdue before the responsible team returns on Monday.
Separate the reminder deadline, delegation deadline, and escalation deadline. A reminder increases visibility without changing ownership. Delegation assigns the task to another qualified person. Escalation indicates that the normal decision path has failed and requires a manager, process owner, or specialist control function. For every deadline, define the starting event, pause conditions, resume behavior, and whether resubmission continues the existing clock or starts a new one. Without those definitions, similar requests can receive different treatment after corrections or integration retries.
- Low risk and reversible: Delegate earlier while keeping the original approver informed.
- High risk or irreversible: A timeout must never imply consent; escalate or stop the process.
- Operationally urgent: Shorten the window only with an added confirmation or retrospective review.
- Dependent on external data: Pause the business clock when required data is unavailable, while monitoring the technical incident separately.
Make escalation bounded, observable, and safe
An escalation chain should not forward upward forever. Each workflow class needs a defined terminal owner, such as a department head, process owner, security reviewer, or compliance function. The terminal rule must specify whether to stop, reject, or enter manual handling. For payments, access grants, contracts, and sensitive data operations, failing closed is usually safer than approving by default. A reversible, time-sensitive, low-risk action may justify conditional execution, but it should create an explicit obligation for later review.
Before release, test planned leave across date boundaries, chained delegation, an unavailable delegate, organizational changes, duplicate notifications, resumption after corrections, and failed delivery through email, LINE, ERP, or CRM integrations. Observability should cover more than processing time. Track cases with no eligible approver, repeated escalation, manual reassignment, policy evaluation failure, and notification failure. An operations screen should show the current owner, next deadline, intended escalation target, and the rule that selected them. If operators must reconstruct those facts from logs, the workflow is not yet operationally complete. An integration team can help turn identity, organization, calendar, and business-system data into one testable decision model.