No public API replacement is planned for this endpoint before the March 31st, 2024 deadline.
To initiate a role refresh, you can select “Apply Changes” in the roles user interface to refresh roles for all identities. Alternatively, you can use the following APIs to process one or more identities, which will result in roles being recalculated for the identities being processed.
For more information on applying role changes, please see this document.
so you mean the deadline will be moved? because we need that endpoint to refresh the roles.
BTW, IDN still uses that API call.
IDN will not be affected since it will have access to internal APIs that will allow the “Apply Changes” button to continue working. Due to resource constraints, we will not be able to provide a public endpoint for this functionality in time for the deadline.
Can you help me understand your use case for programmatically refreshing roles instead of manually applying the changes when a role is updated? There might be a path forward based on your particular use case.
we create and update roles every day, we are a team of 4 doing it, so we cannot be triggering the update each time we modify a role as it triggers all the identities to be evaluated.
So we have a scheduled task that triggers the role refresh every night … you know like the feature that IDN used to had and decided to remove.
Thank you for clarifying your scenario. However, this is a private API that had no SLA, and due to resource constraints we will not be able to prioritize a replacement for this endpoint over other higher priority APIs. For the time being, the recommended approach is to manually press the “Apply Changes” button in the roles UI when all of your daily role changes are done.
or, since there are not enough resources on your side, you can push the deadline until you can provide a proper and complete replacement of all the API endpoints that are used by your clients
IDN admins do need a way to trigger (or schedule) one big role refresh, rather than firing off a bunch of them when role changes are made. After all, SailPoint pays for the CPU time to do all those refreshes, costs that will be passed on to customers, when we could just be paying for one.
For the record, I’ve worked with customers who have tens of thousands of roles, with new roles being created for every combination of (retail branch + job code), or one role per university course per semester, or similar. It’s particularly common with SAP and mainframe banking software. Gustavo’s use case isn’t that unusual.
If we create a role, enable it and make it requestable, we can’t request it yet through the UI, because in the request center, the UI only shows roles that are visible in search as well. It only becomes visible in search after we perform the apply changes task on all roles. So we don’t only use the apply changes button to trigger provisioning, but also to be able to use the request center for that role.
Processing identities doesn’t have an effect on this.
Hello @colin_mckibben any news about the deprecation of /api/role/refresh? Sailpoint is going to create an alternative API to do the same?
Regards,
Bea.