Invoice exception approval with escalation and business-hour SLAs
An accounts payable group uses CAI for invoice exception approval. Invoices over $10,000 with a purchase-order mismatch are routed to the AP manager. If the manager does not respond within 4 business hours, the task must escalate to the CFO; after 8 business hours it is auto-rejected and the vendor is notified. The team handles about 1,200 exceptions per month, and roughly 30% escalate. The current process uses a 24-hour wait step, keeps task state only in process memory, and loses escalation when the process server restarts. Approvers also complain that weekends count against them. Audit needs a complete trail of who approved or rejected, when, and with what comment. The company has offices in three time zones and a holiday calendar that changes annually.
1. Model the approval, escalation, and auto-rejection behavior using CAI process and human-task capabilities. What must be persisted, and what must not run only in memory?
Read the worked answer
Model the approval as a human task created by the process, with the invoice ID, amount, mismatch reason, approver, due date, and a task ID persisted in a database or process object. The process then waits for a signal (approve or reject) rather than sleeping in memory. Escalation and auto-rejection should be driven by a scheduled or timer-based process that queries open tasks by due date and state, not by a long-running wait step that depends on one process instance staying alive.
Persist state transitions: PENDING_MANAGER, ESCALATED_CFO, APPROVED, REJECTED, AUTO_REJECTED, with timestamps and actor. The 24-hour wait step is wrong on two counts: it ignores the 4-hour and 8-hour policy, and if state is only in memory a server restart loses the escalation. On restart, the timer process must be able to reconstruct open tasks from persisted state. Auto-rejection should also enqueue the vendor notification exactly once, keyed by invoice ID and state.
2. How should business hours, time zones, and holidays be handled so the 4-hour and 8-hour thresholds are correct and escalation fires once?
Read the worked answer
Do not compute 4 hours as 14,400 seconds of elapsed time. Store a business calendar with work hours, time zone per office, and holidays, and calculate the due timestamp in the approver’s business time zone. For a task created Friday at 16:00 in New York, 4 business hours crosses the weekend; the escalation due time should be Monday or the next business day, not Friday night.
The timer process should run frequently, for example every 15 minutes, select tasks whose due timestamp is past, and transition them atomically. Use a state guard such as UPDATE ... WHERE state = 'PENDING_MANAGER' so two timer runs cannot both escalate. When escalating, create a new CFO task and close or mark the manager task as escalated; do not mutate the original task’s history. Recompute the 8-hour deadline from the original creation time or per policy, and store the policy version so a calendar change next year does not retroactively change open tasks.
3. What audit and concurrency controls prevent duplicate decisions when two approvers act at the same time?
Read the worked answer
Persist a task version or row version and require it on every decision. When an approver submits, the service performs an atomic conditional update from PENDING or ESCALATED to APPROVED or REJECTED; the loser of a race gets a conflict and a message that the task was already decided. Do not rely on reading the task, checking status in process logic, and then writing, because two approvers can interleave.
Record actor, timestamp, comment, decision, and the task version in an append-only audit table. If the CFO and manager act at the same time, one decision wins by policy, for example the first valid decision wins or the CFO overrides under an explicit rule; encode that rule, not an accident of timing. The process that waits for the signal must handle duplicate signals idempotently. Notify the vendor only after the winning decision is committed, using an outbox pattern keyed by invoice ID so a retry does not send two rejection emails.