Routinely refresh identities

Is there a way to automate the routine refresh of identities? My organization is running into issues with roles not assigning and lifecycle states not being calculated in a timely manner due to lack of identity refreshes. My initial thought is to have a workflow run that kicks off identity refreshes for all users every hour, but this would not work as I have more than 100 identities to refresh and the workflow loop can only iterate over a max of 100 objects.

If there is not an easier way to automate the refresh of all identities, is there a way to iterate over more than 100 elements in a Workflow loop?



Before exploring ways to schedule your own processing I would first look into why the event based processing isn’t performing as expected.

There is an API that takes a list of 250 identities that could be used for this but the API explicitly states the following:

This operation should not be used to schedule your own identity processing or to perform system wide identity refreshes. The system will use a combination of event-based processing and scheduled processing that runs every day at 8:00 AM and 8:00 PM in the tenant’s timezone to keep your identities synchronized.


1 Like

To overcome the limitations of the triggering 100 elements you can go for recursive loop

You can use this API to refresh identities in a specific Identity Profile
where :id is that of Identity Profile

You can have a task scheduled to run a PS script that will send a POST request to above API for each of the Identity Profiles that are to be refreshed.

However, I agree with @ruben_elizondo that event based processing should be taking care of refreshing any identity that would have it’s attributes updated.

Hey Ruben, I agree but I am not sure why the event based processing isn’t performing as expected. I’m not sure what else I can do to help debug SailPoint’s API. My guess is that it is not working due to the assignment criteria being an entitlement.


Do you mean that the assignment criteria for a role is the presence of an entitlement? How is that entitlement provisioned or assigned?

Are there any identity attributes that are calculated before the role assignment?

To start to trouble shoot, I recommend starting with a single identity and monitor the events through search. Event-Based Processing happens when an aggregation or provisioning process modifies an identity.

One theory:
Whenever a connector provisions to a target, there should be a single account aggregation that happens just after provisioning to pull in the data. If the connector is a jdbc, web services or custom connector, you have to explicitly set that up. Otherwise the provisioned entitlement won’t get detected until the next aggregation and the identity processing won’t trigger until then.

If that isn’t the case but the flow is still started with a provisioning event, you could set up a workflow to trigger after a provisioning complete event (Provisioning Completed Trigger) and then process that single identity using an HTTP action workflow step with this endpoint: POST .

That would be much better than batch identity processing in terms of not queuing up unnecessary processing jobs but it shouldn’t be neccessary to do this. A provisioning event (or aggregation) should trigger the processing.

I know Workflows is convenient as it is OOTB.

You can create some script (PowerShell or Python or as per your convenience) to trigger the API call to refresh Identities and schedule it in IQ Service server.

Hi Ruben,

You are correct that for the roles I’m seeing issues with is the assignment criteria is an entitlement. I have seen roles get assigned as expected when the assignment criteria is an account or identity attribute value. The initial entitlement can be considered birthright and exists on the account outside of SailPoint role management.

The connector in question is Active Directory. AD Account aggregation, entitlement aggregation, and regular identity refresh did not trigger role assignment in this case.

Another use case where we will benefit from having an hourly full identity refresh is for calculating lifecycle states. We have logic to move users to inactive at 5pm on the user’s end date and we are not seeing lifecycle state update at 5pm unless we manually process the identity. This timing discrepancy is unacceptable for my organization and thus I think an hourly refresh is unavoidable and will fix multiple issues I am seeing (lifecycle state calculation and role assignment and likely other issues that will arise in the future).