ISC process identity history

Issue: IT is related to processing identity. In our sandbox environment there is an attribute name “Lifecyclestate” whose value is (active or inactive) based on the enddate we put for a user. Even the enddate is passed, the lifecycle state does not turn to inactive for a user. We had to manually go to specific user UI and execute an action of “process identity” to inactivate user. this is manual process

Question: Is there a way for me to know sailpoint auto process identity history? I’m having an impression that process identity happens every day 8am and 8pm from sailpoint. In my case the auto process identity is not picking the users which would have updated the lifecyclesttate value from active to inactive. Any suggestion?

Identity attributes should also update when the authoritative source is aggregated and when clicking ‘apply changes’ after making updates to the mapping page.

We are experiencing the same situation. Identity Refreshes are not occurring on identities unless there has been a change on an aggregated source, or it’s manually kicked off via ‘apply change’ or ‘process identity’.

There is Time-Based Processing that looks to be a good fit for these scenarios. Haven’t tried it yet, but might be worth looking into.
Processing Identity Data - SailPoint Identity Services

I was also under the assumption that the 8 am/pm would do this - however in the same document linked above has the list of criteria for scheduled processing.

  1. Auto “Process Identity” typically runs twice daily (e.g., 8 AM and 8 PM) as part of SailPoint’s scheduled tasks — but the exact schedule depends on your tenant configuration and system load.
  2. You can check identity processing logs/history by raising a support request — ISC does not expose this directly via UI or API today.
  3. If identities are not being processed automatically, it could be due to misconfigured identity refresh triggers, data feed delays, or improper lifecycle configuration.
  4. To ensure timely processing, consider building a workflow or rule trigger that listens to attribute changes (like endDate) and explicitly invokes “Process Identity.”
  5. As a workaround, a scheduled job or external script using the Identity API can loop through identities with expired endDate and trigger processing via API (if enabled).

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.