I’ve created AD groups and assigned them as entitlements to Access Profiles. We have an access request and approval process managed through ServiceNow, where users submit requests for Access Profiles rather than directly requesting AD groups or entitlements.
Recently, due to a business process change, I had to rename the Access Profiles. The updated names are also reflecting correctly in ServiceNow to avoid any sync issues.
I then created a Provisioning Completed subscription to trigger a webhook URL. This event should fire once the access request and approval process is completed by the approvers.
In the subscription, I’m using a filter similar to the following:
This works as expected when I submit requests via the API:
{{baseUrl}}/access-requests
However, when requests are submitted through SailPoint Request Center or ServiceNow, the subscription is not getting triggered.
I’m concerned that the subscription may not be recognizing the updated Access Profile names. With the Postman API flow, we pass the Access Profile ID directly, which is why it appears to work correctly.
Has anyone encountered a similar issue where the trigger was not firing for SailPoint Request Center or ServiceNow requests? If so, how was it resolved?
“Provisioning Completed” event should be triggered for all provisioning completion events, regardless of whether they originate via API, Request Center, or SNOW.
To confirm this, you can simply create a workflow with the same trigger and filter and validate the behavior. We currently have a workflow using this trigger, and it is working correctly.
Also, one remark regarding your filter: for attributeRequests, a dot (.) is added before [
We don’t currently have the Workflow feature enabled, so I’m unable to test it that way. However, I did update the filter by removing the extra dot (.) and submitted another access request.
Even after the provisioning completed successfully, the trigger still did not fire. I’m not sure what might be causing the issue at this point.
Yes, I tested it again after removing the filter, and I was able to identify that the issue is related to the Access Profile name. It appears SailPoint is still referencing the old Access Profile name instead of the updated one, which is why the following condition is not working:
Is there any background sync process or database refresh that updates Access Profile names internally? I updated the names about two days ago, so I’m not sure if there’s a propagation delay or scheduled sync involved.
Even though if you’ve applied the changes, still sometimes it takes a while to reflect the changes across the tenant as I’ve experienced this behaviour with some other changes. I would suggest give it some time (few hours or so) and then check it again or raise it with SailPoint support team.
Hi everyone - Thanks for all the responses. It looks like this is a known SailPoint issue where changing the Access Profile name from the UI only updates the display name and not the actual Access Profile name stored in the backend/database. Because of this, filters based on the updated names do not work as expected.
There is already an idea/request GOV-I-2300 submitted for a proper solution to address this limitation. Hopefully, SailPoint prioritizes it soon.
Yes, this usually happens because Request Center and ServiceNow requests generate different provisioning payloads than direct API requests. Your filter is likely matching entitlement-level data for API calls, but not the Access Profile-based payload coming from UI/SDIM flows.
Check the actual Provisioning Completed event payload from Request Center requests and update the JSONPath filter to match the generated attributeRequests or requestedItems structure.
Your situation with the Provisioning Completed subscription not triggering for requests submitted via SailPoint Request Center or ServiceNow, while working via API, is a known challenge that often relates to how attribute values and identifiers are handled differently across request channels. Sailpoint has still not worked on the Idea as it was raised from Feb 2023. Hope they prioritize this for speedy solution for your case.