Introduction
- Why: Sometimes you just need to refresh a single role in SailPoint Identity Security Cloud without triggering an “Apply Changes” for the entire tenant.
- Problem: Currently, the UI does not offer a simple way to refresh just one role. Clicking “Apply Changes” impacts all users and can take a significant amount of time.
- Who Is This For? This solution is primarily designed for large organizations (100k+ identities) where global role refreshes can take significant amounts of time and system resources. For smaller organizations (under 5k identities), you are likely better off simply using the out-of-the-box “Apply Changes” button, as the performance impact is minimal.
- Goal: A streamlined solution allowing administrators to select an individual role and refresh only the identities associated with that role.
Solution Overview
- Tech Stack: 1 Form + 2 Workflows (Launcher & Paginated Worker)
- High-Level Flow: Using a custom interactive form, an administrator can select the specific role they wish to refresh. A primary workflow takes this input and sends the role data to a dedicated “Paginated Worker” external trigger workflow. This worker handles the pagination and identity refresh API calls in chunks of 250, avoiding timeouts and efficiently processing the users.
What It Can and Cannot Do
Before implementing, it is important to understand the boundaries of this solution.
What It Can Do:
- Update Entitlement/Access Profile membership when a new item is added to the role membership.
- Update when a user is added to the role via the identity list. It adds the role to their cube along with the assigned Entitlements/APs.
- Update when a user is removed via the identity list. It removes the role and the associated Entitlements/APs.
- Update when membership criteria are removed, causing an identity to fall out of the role. The workflow will remove the user from the role and strip the assigned Entitlements/APs.
What It Cannot Do:
- Refresh Newly Added Role Membership Criteria: For this scenario, you still need to use the native “Apply Changes” button.
- When Removing Entitlements From Roles: This workflow does not automatically remove the access from the user. You must remove them from the membership of the role for the access to be completely removed from the user.
User Interface (Forms)
We start with an interactive form. Since we cannot build this directly into the role management UI, the form provides a simple drop-down to pick the role and a toggle for “Identity List Refresh Needed?” This option is crucial because roles can have members assigned via criteria or specifically via an identity list, and they require different API approaches to refresh.
Form Definition Code:
Form-Role-Selector.json (3.1 KB)
The Workflows & API Calls
This solution relies on two workflows working together.
1. The Launcher Workflow (Role Refresher)
This workflow uses an Interactive Trigger. When launched, it presents the form to the user. Once submitted, a loop iterates through the selected roles and makes an HTTP request to our secondary worker workflow, passing along the role ID and the user’s choice for the identity list refresh.
Launcher Workflow Code:
Workflow-RoleRefresher.json (4.3 KB)
2. The Paginated Worker Workflow
This is an External Trigger workflow where the heavy lifting and API calls occur. Based on the form input, it branches into two different paths:
Path A: Standard Assigned Identities (Pagination)
If the user selected “No” for the identity list refresh, the workflow uses the /roles/v1/{roleId}/assigned-identities endpoint.
- It fetches the assigned identities in chunks of 250.
- JSONPath Conversion: The API returns an array of objects, but the process endpoint expects a simple array of strings (Identity IDs). We use a custom Define Variable step with the JSONPath expression
$.hTTPRequest.body[*].idto cleanly extract just the IDs into a new array. - It then submits this array to the
/identities/v1/processAPI. If exactly 250 identities are returned, the workflow recursively calls itself with the offset increased by 250, paginating through all members.
Path B: Identity List Refresh (No Pagination)
If the user selected “Yes” for the identity list refresh, the workflow takes a different route because fetching the identity list requires a direct GET to the /roles/v1/{roleId} endpoint.
- The Limitation: Role objects currently limit the returned identity list membership array to a maximum of 500 users. Because of this, this path does not perform recursive pagination.
- The Workaround: To process up to the 500 maximum, we use Define Variable steps with JSONPath slicing. We grab the first 250 users (
$.hTTPRequest4.body.membership.identities[0:250].id) and the next 250 users ($.hTTPRequest4.body.membership.identities[250:].id) to avoid reprocessing identities already captured in the first slice. We then execute the/identities/v1/processAPI calls sequentially for both slices.
Worker Workflow Code:
Workflow-PaginatedIdentityRefresher.json (10.8 KB)
Considerations & Best Practices
- Permissions: Restrict access to this form to administrators who understand the impact of manual identity processing.
- API Limits & Versioning: The
/identities/v1/processendpoint is powerful. Paginating at 250 ensures we stay within acceptable processing limits and timeouts. Note: The identity processing endpoint used in this solution is currently a v1 API. Please verify the endpoint version and review the logic if a newer endpoint becomes available in the future. - Testing: Always validate the form and workflows in a sandbox or non-production tenant before deploying.
Conclusion
- Summary: This solution provides a targeted approach to role refreshing, saving time and system resources compared to a global tenant refresh.
- Call to Action: Have you built any interesting workflows using interactive forms or pagination? Let me know in the comments below, and feel free to reach out if you have questions about extending this functionality!