Can access request approvals be routed to requester’s SVP via Access Request Submitted trigger in the workflow?
Hello Selvarani. Yes, this should be possible using Adaptive Approvals.
Create a workflow with the Access Request Submitted trigger and use $.trigger.requestedBy.id to retrieve the requester (or $.trigger.requestedFor.id if you mean the SVP of the person receiving the access). You can resolve the SVP from an identity attribute or, if the hierarchy depth is fixed, chain Get Identity actions using each result’s managerRef.id.
In the Approval Policy action, select Identity (Other) and map the resolved SVP identity ID from the earlier step. After enabling the workflow, select it as the Approval Type for the relevant role, access profile, or entitlement. The workflow runs only when an access item linked to it is requested.
If the hierarchy depth varies, I would suggest mapping or calculating an svpId identity attribute from the authoritative data rather than trying to traverse an unknown number of manager levels in the workflow.
The external Access Request Dynamic Approval trigger is a separate option for an external request-response service. It can add one additional identity or governance group as the final approval step
Thank you, Harish. Would you be able to provide a sample workflow with an approval step? I already have the SVP identity attribute so retrieving the approver is straightforward. Just want the request to go through this approval once the request is submitted.
Since you already have the SVP identity attribute, this can be done with a simple four-step workflow. Here is a simpler version that covers just the SVP approval without any extra conditions or branching:
Step 1 - Trigger: Select Access Request Submitted as the trigger. This fires when someone submits an access request for an item linked to this workflow.
Step 2 - Get Identity: Add a Get Identity action. In the identity ID field, switch to variable mode and pass $.trigger.requestedBy.id. This pulls the requester’s identity attributes, including your SVP attribute, into the workflow data so the next step can use it.
Step 3 - Approval Policy: Add an Approval Policy action. Set the Approval Type to Single and choose Identity (Other) as the Reviewer Category. Switch the reviewer field to variable mode and map the SVP attribute from the Get Identity output. The attribute must contain the SVP’s ISC identity ID. If it stores a name or employee number instead, you would need a Get List of Identities step or an API lookup before this step to resolve the identity ID.
Step 4 - Success: Add a Success end step to close the workflow.
Once the workflow is enabled, go to the role, access profile, or entitlement that needs this approval, set it to require approval, select Workflow as the Approval Type, and choose this workflow. The SVP will then receive the approval request under Approvals > Access Requests when that access item is requested.
Use $.trigger.requestedFor.id instead of $.trigger.requestedBy.id in Step 2 when the approval should go to the SVP of the person receiving the access rather than the person submitting the request.