I’m building an approval workflow that needs to walk up an identity’s manager chain (manager → manager’s manager → …) until it finds one whose Manager_Level attribute equals a target value, then routes the approval to that person. Max chain depth can be 13 per identity, so I’m trying to use the new Serial Loop → While Loop operator, is this possible? Or should i have 13 if else statements? Any ideas?
Thanks!
I would go with the Serial While Loop rather than creating 13 nested if/else conditions. It will be much easier to maintain and extend in the future.
The workflow itself won’t automatically traverse the manager hierarchy, so during each iteration you’ll need to retrieve the current manager, check whether the Manager_Level attribute matches your target value, and if not, update the current manager to their manager before continuing the next iteration.
Once you find the required manager level, you can exit the loop and route the approval to that identity instead of continuing through the remaining levels.
The only thing I’d recommend is building a small proof of concept first to verify that your workflow variables are updated as expected between iterations, especially if you’re storing the current manager reference. If that works, I don’t see a reason to maintain 13 separate conditions.
Yes, I think this is possible with the new Serial Loop → While Loop, and it would be much better than creating 13 different If/Else conditions.
You can start with the identity’s direct manager, check the manager’s Manager_Level, and if it does not match the target value, move to that manager’s manager. The loop can continue until it finds the correct manager level or reaches the maximum depth of 13.
Once the matching manager is found, you can store that identity as the approver and use Break to exit the loop.
I would also add some fallback conditions, such as:
manager is null
no matching manager is found within 13 levels
circular manager relationship
In those cases, you can route the approval to a default governance team or admin group.
So I would try the While Loop first. Creating 13 If/Else statements may work, but it will be very hard to maintain and troubleshoot later.
The Serial While Loop would be the better approach here, I would not go with 13 If/Else blocks for this.
What I would do first is use Get Identity with $.trigger.requestedFor.id to pull the identity the request is for. Then set up a currentManagerId variable from that identity’s managerRef.id and a counter at 0 using Define Variable. The reason for this extra step is the trigger payload only gives you the requested identity’s ID, not their manager directly. Also worth noting, access requests can be submitted by one person for another, so starting from requestedFor instead of requestedBy would be the safer bet.
For the While Loop condition, something like counter < 13 should work. Inside each iteration, I would first check that currentManagerId is not null using Verify Data Type. Then call Get Identity with currentManagerId and compare attributes.Manager_Level against your target value.
If it matches, I would place the Approval Policy action right there in the matched branch, using that identity dynamically as Identity (Other) for the reviewer, and then Break Loop. I wouldn’t try saving the approver ID to a variable and using it after the loop. Variables updated inside serial loops have scope limitations that can cause the value to not persist outside, so keeping the approval inside the loop would avoid that entirely.
If no match, updating currentManagerId to that manager’s managerRef.id and incrementing the counter should keep it moving up the chain.
For the fallback, if the manager is null or no match is found within 13 levels, routing to a governance group would be the safe option.
Hello Harish, I tried the steps that you mentioned, I’m getting this error - missing IdentityID in requestContext when I’m trying to request that role.
Full error message -
An unexpected error occurred: Approval workflow error: child workflow execution error (type: sp:serial:iterator:workflow, workflowID: , runID: , initiatedEventID: 55, startedEventID: 56): missing IdentityID in requestContext (type: serial iterator failed, retryable: false) (type: WorkflowFailure, retryable: false): child workflow execution error (type: sp:serial:iterator:workflow, workflowID: , runID: initiatedEventID: 55, startedEventID: 56): missing IdentityID in requestContext (type: serial iterator failed, retryable: false) - access workflow execution failed
Hello Aishwarya,
That error is happening because Approval Policy 2 is inside the Serial Loop. The error shows that it’s running in the loop’s child workflow context and isn’t receiving the IdentityID from the access-request context.
I would move the Approval Policy outside the loop.
Before the loop, define selectedApproverId as empty. When the matching Manager_Level is found, update it with $.getIdentity1.id. Also add selectedApproverId == "" to the While condition so the loop exits naturally after finding the approver.
I would avoid Break Loop here because variables updated inside a Serial Loop have shown inconsistent results after a Break.
After the loop:
selectedApproverId has a value, use it in Approval Policy as Identity (Other).The loop should only find the approver. The Approval Policy should run after the loop.
Hi @aishwaryagoswami ,
I would suggest using a Serial While Loop instead of multiple if/else conditions. The loop can traverse the manager hierarchy until it finds the required Manager Level. In this case, you can use the loop only to identify the approver and store the Identity ID. After the loop completes, use that Identity ID in the Approval Policy. This approach is easier to maintain and also helps avoid issues like missing IdentityID in the request context