The Approval That Never Fires
A service catalog item 'New Laptop Request' uses a Flow Designer flow. The flow: (1) triggers on catalog task creation, (2) runs a 'Ask for Approval' action assigned to the requester's manager, (3) on approval, creates a fulfillment task assigned to Hardware Team. Testing shows: requests submitted by users with a manager proceed correctly. Requests from users without a manager (e.g., contractors, the CEO) hang indefinitely - the flow shows 'Waiting' and never advances, and no approval record is created. A separate issue: when a manager is also the requester, the flow still asks that same person to approve their own request. The business wants: no-manager requests to route to a default approver, and self-approval to be blocked.
1. Why does the no-manager case hang with no approval record, and how should the flow be changed?
Read the worked answer
The 'Ask for Approval' action resolves the approver from the requester's manager reference. When that reference is empty, the action has no one to assign to. Depending on the action's configuration, it either waits for an approver that will never exist (so the flow sits in 'Waiting') or fails to create the approval record at all. The flow does not error because the action ran - it just produced no approver.
Fix: add a decision/branch before the approval action that checks whether the requester has a manager.
- If manager exists → Ask for Approval to manager.
- If not → Ask for Approval to a configured default approver (e.g., a group like
IT Approversor a specific fallback user), or skip approval and route straight to the fulfillment task per policy.
Use a flow variable to hold the resolved approver so the approval action always receives a non-empty value. Also add a timeout/SLA on the approval so a stuck approval escalates rather than hanging forever. Test explicitly with a no-manager user before publishing.
2. How should the flow prevent a manager from approving their own request, and where should that logic live?
Read the worked answer
Self-approval must be evaluated at runtime, per request, not configured statically. In the flow, after resolving the approver, add a condition: if resolved_approver == requester, reassign the approval to the next level up (the manager's manager) or to a designated approver group.
Where it lives matters:
- In the flow (preferred here): keeps the rule visible with the process and easy to change without touching platform-wide logic.
- A before-query/business rule on the approval table can enforce the rule globally, which is stronger but risks unintended side effects on other approval processes.
Best practice: implement the check in the flow and add a lightweight guard (e.g., a business rule or approval-action condition) so the rule can't be bypassed by a different entry point. Document the fallback approver chain: manager → manager's manager → approver group. Verify with a test where requester and manager are the same user.