Invoice Approval: Forty Instances Stuck in Procurement
An invoice approval process splits into three parallel paths: Cost Center approval, Procurement review, and a Vendor Onboarding subprocess. After a procurement reorg, 40 instances have sat in 'Awaiting Procurement' for three weeks. The task is assigned to the group 'Procurement Reviewers', whose membership syncs from Active Directory and which currently has zero active members. The Vendor Onboarding path is a parallel (AND) branch even though onboarding is only needed for new vendors, so every instance waits for it. The process owner wants a three-day escalation sent to the CFO's individual account and asks you to implement it as designed.
1. Diagnose why the instances are stuck and propose changes that prevent recurrence, not just a one-time cleanup.
Read the worked answer
The proximate cause is structural, not operational: group assignment is resolved when the task is created, and a task assigned to a group with no active members has no eligible claimant. Nobody gets an error, no exception is thrown, and the process simply sits there. Deactivated users in a group are the same trap - they still exist as members but cannot log in.
Cleanup: reassign the 40 open tasks (process instance management, or a task report filtered on the group) to a populated group.
Prevention, in order of leverage:
- Never let the only eligible assignee be a group with no members. Assign to a group plus one or more named backups, and have the AD-driven group own a process owner who monitors it.
- Escalate to a group, not to a person. Escalation reassigns; if it reassigns to an individual who is on leave or deactivated, you have recreated the same stall one level up. Escalate to 'Procurement Managers' and add a second escalation step if needed.
- Make stuck instances visible. Configure a process-instance timeout or aging-task alert so a task open beyond the SLA notifies the process owner rather than waiting for a user to complain after three weeks.
- Fix the membership pipeline. If AD sync is authoritative, the empty group is an integration failure; alerting on 'group with zero active members that owns open tasks' catches it before 40 instances accumulate.
2. Should Vendor Onboarding be a parallel branch? Explain what modeling change you would make and the gateway-matching rule you must respect.
Read the worked answer
No. An AND (parallel) split means every token must reach the matching join, so the process will wait for Vendor Onboarding on every invoice - including the majority where onboarding is irrelevant. That is not a bug in the subprocess; it is the semantics of the gateway, and it makes the branch a permanent bottleneck.
Change: put a decision ahead of the branch and model it as an XOR (exclusive) split, with the onboarding subprocess on the 'new vendor' path and a direct path to the join for the rest. The condition derives from process data (isNewVendor or the vendor's onboarding status), not from a hardcoded default.
The rule that bites people: the join must match the split. An XOR split paired with an AND join will deadlock - the AND join waits for a token from the path that was never taken - and an AND split paired with an XOR join lets the first arriving token close the process while the other branches are still open. Model the split and join as a matched pair and verify every path between them.
If onboarding truly must remain parallel for compliance reasons, the honest alternative is to keep the AND split and make the onboarding path an auto-completing stub for known vendors, so it satisfies the join without human work. That keeps the gateway semantics intact at the cost of a slightly noisy model.
3. Implementing the CFO escalation as requested: what will you build, and what will you push back on?
Read the worked answer
What I would build: an escalation on the Procurement user input task - after three business days, reassign to a group whose membership includes the CFO and the procurement managers, raise the priority so it sorts to the top of the task list, and record the escalation in a process variable so reporting can count how often it fires.
What I would push back on: escalating to one named individual account. It fails in the two situations escalation exists for - the CFO is travelling, or the CFO's account is deactivated and the task becomes permanently unclaimable, which is the exact failure we are already cleaning up. A group gives the same visibility with a fallback claimant. I would also confirm the CFO actually wants task-list work, since executives often expect a notification rather than a claimable task; if so, the escalation should notify and reassign to a delegate, not to the CFO directly.
Two details worth confirming before build: whether the three days are calendar or business days (Appian escalations count elapsed time unless you account for a business calendar in your SLA reporting), and whether completion of any one of the parallel branches should cancel the escalation. Escalation fires based on the task still being open, so a stalled sibling branch will not trigger it - which means the escalation covers Procurement only, not the branch that is actually the bottleneck.