Identities in the Inactive (long-term) lifecycle state are no longer included in the daily 1:00 AM CT synchronization job. This reduces overnight processing time, particularly for tenants with large numbers of terminated or archived identities.
What this means for you
Faster completion of scheduled overnight jobs
Reduced system resource consumption
What to know
Identities in the Inactive (long-term) state are already excluded from regular identity processing. With this update, they will also be excluded from certain background maintenance jobs - in this case the SYNCHRONIZE_IDENTITIES job that keeps Search up-to-date.
This internal maintenance job only keeps Search data in sync.
As a result, details related to inactive identities (such as role or entitlement names) will no longer be up-to-date in Search if those names change after the identity becomes inactive. For example, if a role assigned to an inactive identity is renamed, the updated name will not appear when viewing that identity in Search.
I need clarification on this new development. Should we understand that an identity marked as long‑term inactive will no longer be able to transition to another status without manual action ?
Particularly when the end date is modified in the golden source?
Data changes trigger another type of Identity Processing - depending on your case you might be fine.
Lifecycle State changes for Identities in Inactive long-term already only works today if the data change on the authoritative source causes the identity to move into a different Lifecycle state immediately. This triggers an Event Based processing ( Processing Identity Data - SailPoint Identity Services) that runs immediately after the data change.
We had a case where we needed the LCS to change some time after the data, and that did not work - so we needed to control when we received the data change to enable the change via the Event-based processing.
But I agree that it would be nice to have some clarification on the impact of this.
Johanne is spot on - changes which are aggregated from a source still trigger attribute promotion and lifecycle state changes. If there is a logic associated with that lifecycle state that changes without an attribute change (e.g., do something x days after y), than the lifecycle state will not be updated.
We’d recommend leveraging the nextProcessing attribute in order to ensure refresh is run for inactive (long-term) identities at specific times, supporting lifecycle state changes where silent changes are necessary.
Hi Bennet - just an FYI from our use case, the “nextProcessing” attributes is also not applied in the Inactive (long-term) - we found out the hard way, and that’s how we ended with the Event-based approach.
A lifecycle state change will be possible if the aggregated source changes it directly
If the lifecycle states are not directly based on a source aggregation but on a calculation of attributes updated by source aggregation, then they will not be updated (for example, if lifecycle states depend on end date attribute)
So any lifecycle state based on a transform calculation will not be updated.
We will be hugely impacted as all of our identities with an end date superior to 1 month in the past are currently in long_inactive state.
Therefore, we will need to process these identities every day in order to check none have been reactivated. Are there any other options you could recommend other than using the “nextProcessing” attribute ?
I had an inaccuracy in my previous message which was edited and I’ll call out here.
If ISC aggregates changes from a source, we will run refresh on the identity for which changes were aggregated, calculations and all.
Your identities in inactive (long-term) will be refreshed if there are any changes which are aggregated into ISC. If the changes are based on dates which will not have changes aggregated in, we’d recommend leveraging the nextProcessing attribute which runs refresh for identities regardless of LCS.
If the above doesn’t work for you, please reach out via my calendly link for me to better understand your setup and make better recommendations. Also, reach out via message and we can work with your CSM to have the feature flag disabled in your environment.
The nextProcessing attribute should work for identities regardless of lifecycle state. If you’re interested, please schedule time via my calendly link so I can learn more about your implementation and help get it working.
I once read that the ‘nextProcessing’ flag only works if it is set more than 24 hours in the future. Is this still the case? If not. Won’t this create a time interval where rehires would fail? The first source change based refresh will not yield updates because the change is time bound and would happen only after a couple of hours, but it then not get calculated since nextProcessing is too close to the current date?
That’s correct - the nextProcessing attribute will not run if it is set within 24 hours of the current time (e.g., you set it five minutes in the future). It was created with joiner / mover / leaver flows in mind and typically start dates and end dates are set more than 24 hours in advance of the identity’s start / end dates.
In cases where you need to do an urgent refresh, you should select an identity to run a refresh or refresh via the API.
‘Typically’, but there are plenty of times when that 24 hour+ isn’t a reality - even for joiner / mover / leaver scenarios.
I think you missed the reality of the situation that your customers find themselves in.
”In cases where you need to do an urgent refresh, you should select an identity to run a refresh or refresh via the API.”
Why make us jump through additional hoops?
But the thing is that it is not an urgent refresh, if HR administrated a rehire whose first lifecycle state (not necessarily active, could be an initial preparation phase) should activate based on a date time that is in 20 hours from now, there is no urgency. Refreshing now does not have any impact. But the aimed refresh where it would have an impact will not happen due to this limitation.
This would be an example of a simple rehire use case without urgency that is now failing because of the 24 hour constraint.
I would consider being 20 hours on time before the first preparation phase starts a reasonable use case that should be met by SailPoint. It is an argument why a next processing date time should be editable with a value that is less than 24 hours in the future.
We are removing Inactive (long-term) identities from the overnight SYNCHRONIZE_IDENTITIES job which keeps search up to date.
Identities in the Inactive (long-term) state are already excluded from identity processing.
What does this mean for you?
Details (such as role or entitlement names) related to identities in the Inactive (long-term) lifecycle state will no longer be up-to-date in Search if those names change after the identity becomes inactive. For example, if a role assigned to an Inactive (long-term) identity is renamed, the updated name will not appear when viewing that identity in search.
This change improves system efficiency by avoiding updates to identities that are no longer active.
My apologies for any confusion surrounding this update! The announcement will be updated to reflect a more clear description of what is changing shortly.
We have started seeing certain identities not move from Inactive_Long_Term to Terminated as our transform is written. The commonality seems to be around, these identities not getting updated timely in the source of truth by managment/hr, which required hr to update their last day of work to a date in the past. We key off a custom attribute called “lastdayofworkreceived” and after 30d in this state, we update the lfs to Terminated where we begin deleting accounts, etc.
Example: Joe left 2025-11-11 but “last day of work” was not entered into the HR system until 2026-02-11, ISC pulled the date into the “lastdayofworkreceived” correctly but the identity never processed and moved into the Termination lfs as expected, 31days later. We can manually process the identity and it works as expected.
All other timely terminations process as expected. Its only those that are getting back dated that seem to be affected.
We suspect it might be related to the new way you are processing identities for “Inactive Long Term” lifecycle state. Can you verify this?
I can confirm that the issues you’re experiencing is not related to the changes to the SYNCHRONIZE_IDENTITIES job which inactive long-term identities are now excluded from. The changes made here will simply not write changes to inactive long-term identities to search, meaning inactive long-term identities may go stale in search over time.
By RSVP’ing to this event you will be reminded of this release prior.
