I’m working on a workflow that uses the Submit Access Request step. The requirement is for the access to be provisioned directly without any additional approvals.
However, since the Global Approval Policy is enabled, the access request generated by the workflow goes through the approval process again.
I tried using Adaptive Approval, but I’m not able to approve the request right away within the same workflow. To process the approval, I would need to create another workflow triggered by the approval event.
For this use case, I’m already using two workflows and would prefer not to introduce a third workflow just to approve the access request.
Is there any way to automatically approve the access request or bypass the approval step from within the second workflow itself?
In the workflow, get the approval ID via request id from the previous submit step’s response. Use the approve-access-request-v-1 | SailPoint Developer Community API call to approve it at all levels via additional HTTP steps. Wait a few seconds between each level of approval for the internal temporal workflow to catch up.
I tried this, but as far as I understand, we need to add an Approval Policy in the workflow step, right?
When I do that, the access request goes to the approver and gets stuck there waiting for approval. It doesn’t proceed to the next step in the workflow automatically.
Not with the current SailPoint ISC workflow capabilities.
The Submit Access Request action always creates a standard access request, which is evaluated against the tenant’s Global Approval Policy. If the approval policy requires approval, the workflow cannot override or bypass it.
Hello Sandy. You don’t need an Approval Policy step in this workflow. That action is designed for Adaptive Approvals, it creates a new review item and the workflow pauses until a reviewer acts on it. That’s why your workflow gets stuck. Remove it.
What @sushantkulkarni is describing is a different approach. When your workflow submits the access request, the Global Approval Policy creates a pending approval in the background. You then use the same workflow to find that pending approval and approve it programmatically, no extra workflow needed.
Here’s how to set it up step by step:
Keep your Submit Access Request step. The create-access-request API is asynchronous, so the workflow moves on immediately after submitting. The response contains the access request ID inside the newRequests array, specifically at newRequests[0].accessRequestIds[0]. Both newRequests and accessRequestIds are arrays, so multiple identities or access items will produce multiple IDs. Grab that value, you’ll need it in step 3.
Add a Wait step, at least 1 minute. ISC needs time to process the request and generate the approval record from the Global Approval Policy. Without this, the approval won’t exist yet when you try to retrieve it.
Add a Get Pending Access Requests step. Select the identity who currently owns that approval (e.g., the manager or access item owner defined in your Global Approval Policy) as the Reviewer, then apply this filter using the accessRequestId from step 1: accessRequestId eq "<your-access-request-id>". The list-pending-approvals endpoint supports accessRequestId as a filter, so this pulls only the approval tied to your specific request instead of everything in the queue.
Add an Approve Access Request step. Use the Variable Selector to pass the id from the first record returned in step 3. This is the approvalId, which is different from the accessRequestId you used to find it. The accessRequestId identifies the overall request, the approvalId identifies the specific approval record you’re acting on.
If your Global Approval Policy has multiple levels (e.g., manager then governance group), repeat the Wait, Get Pending, Approve sequence for each level and select the appropriate reviewer for that level. The next level’s approval only gets created after the previous one is approved.
The identity performing the approval must either be the current approval owner or have the ORG_ADMIN user level. If the approval isn’t showing up when step 3 runs, increase the Wait duration and check the workflow execution logs.
Once your submit API call gets you back the accessRequestId, wait for a little bit to have the internal SailPoint workflows assign the access request to the first level of approval.
Once it is assigned, use the API to get pending approvals by filtering with accessRequestId.
Once you have the approval object, grab its ID and use it to approve at all levels. Just keep a few seconds of wait time in between each approval, so that SailPoint’s internal workflows finish each level of approval before you start the next one.
I also wanted to check about logging and auditability for this workflow.
I’m using 3 forms in the workflow. The manager approval is handled through a Generic Approval Policy, and the other approval is handled through a form. Once the final form is submitted, I’m provisioning the access directly to the user.
However, I can’t see any events related to these actions in Search. I wanted to know if there is any way to capture logs for these workflow activities. Specifically, I’d like to track:
Form submissions
Manager approvals
Form-based approvals
Is there any way to view these events, store them somewhere, or generate an audit trail for reporting and audit purposes?
There should be some events generated on workflow history tab on the ISC search. Try to search the events for your specific workflow by narrowing the search query down as per your requirements. The query responses can have details you could use.
There are two places to check: Events and Workflow History.
The manager approval through the Generic Approval Policy creates audit events. Search the Events category for type:approval_request_created or type:approval_request_approved.
Form submissions and form-based approvals do not create standalone audit events. Search them under Workflow History, for example:
workflowName:"Your Workflow Name"
AND attributes.displayName:"Manager Approval Form"
AND type:ActivityTaskCompleted
Check attributes.input and attributes.result for the submitted values. Provisioning is tracked separately under Account Activity or Admin > Identity Management > Activities.
Workflow History is retained for 90 days. For longer retention, send the required form and approval details to an external logging system using an HTTP Request step.
@sandy_sandy
Unfortunately, there is no supported way for a workflow to bypass or auto-approve an access request that is subject to the Global Approval Policy when using the Submit Access Request action. The request will always go through the configured approval process.
If the approval policy applies, your options are typically:
Use Adaptive Approval and process the approval through a separate workflow.
Modify the approval policy logic to exclude these requests.
Provision the access directly through another mechanism (for example, provisioning workflows/API) instead of using Submit Access Request.
So, if the request is created via Submit Access Request, the workflow itself cannot immediately approve the resulting approval item within the same execution. A separate approval process/workflow is generally required.