Approval Routing When the Approver Is on Leave
A purchase request process routes to the requester's direct manager for approval, then to Finance for requests over $10,000. The manager is resolved from an HR record type at the moment the task is created. Three problems surfaced in the first month: (1) when a manager is on leave, requests sit untouched until someone notices, sometimes for a week; (2) when an employee changes managers mid-request, the request still goes to the old manager; (3) a request for exactly $10,000 was routed to Finance by one path and not another. The team's instinct is to add a reminder and an escalation. Stakeholders also want a full audit trail of who approved what and when.
1. Design the handling for the on-leave manager case. What belongs in the process model versus the data model?
Read the worked answer
The wrong answer is "add an escalation timer." A timer treats the symptom (nobody acted) without addressing the cause (the task was assigned to someone who cannot act).
Recommended design:
- Model leave as data: an
Out of Office/ delegate field on the HR record, with a start and end date and a designated delegate. This is a fact about a person, not a process step. - At the point of task creation, resolve the approver through a single reusable expression that checks: is the manager currently out of office? If yes, route to the delegate (and, per policy, CC or notify the manager). If no, route to the manager.
- Keep the escalation timer as a backstop for the case where nobody acts - delegate included. That is its correct role: not the primary mechanism, but a safety net with a defined SLA (e.g. 3 business days) that reassigns to the manager's manager and logs the escalation.
Why this split matters: putting leave logic in the process means every new process must reimplement it, and mid-flight changes are hard. Putting it in an expression backed by data means one change propagates everywhere, and the rule is testable in isolation. The audit trail then records both the original intended approver and the delegate, which is what auditors actually want to see.
2. Address the mid-request manager change and the $10,000 boundary. What is the underlying principle?
Read the worked answer
Both bugs are the same bug: an ambiguous rule evaluated at an unspecified time.
Mid-request manager change. The process resolved the manager once at task creation and never revisited it. Decide the policy explicitly and encode it:
- Snapshot at submission (approval goes to whoever was manager when the request was raised) - defensible for accountability, and simpler.
- Live resolution (approval goes to the current manager) - defensible for authority, but requires re-resolution and a documented rule for what happens if the task is already open.
Either is acceptable; what is not acceptable is leaving it implicit. Whichever you pick, record which manager was resolved and when, so the audit trail is unambiguous.
The $10,000 boundary. "Over $10,000" and "$10,000 or more" are different rules, and the two paths evidently encoded them differently. Fix: define the threshold once as a constant or a reference table, and express both paths in terms of it (amount > threshold vs amount >= threshold). Never hard-code the number in two places. Write a test case at exactly the boundary, one cent below, and one cent above - boundary values are where routing bugs live.
The principle: every routing rule needs one definition, one evaluation point, and an explicit temporal semantics. Most "process bugs" in review are really unspecified rules that two developers implemented differently.