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.
By RSVP’ing to this event you will be reminded of this release prior.
[2/16/26] – Available in Sandbox
[2/23/26] – Available in Production
Resources
If you’d like to discuss this change or how refresh and provisioning work for you, feel free to schedule a meeting here: Calendly Link. This link will expire after 30 days.
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.
By RSVP’ing to this event you will be reminded of this release prior.
