ISC account retention for only specific accounts

:bangbang: Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.

Hello everyone,

I’m faced with a challenge in front of me, our ISC is setup to no longer aggregate accounts out of SuccessFactors after 150 days, ISC also deletes the identtiyobject around this time. SuccessFactors is managed by our HR and when we have an employee enter severance a date gets assigned, and when they enter their severance period the account is flagged as terminated.

If this date is beyond 150 days, and ISC deletes the object. When the severance date arrives SuccessFactors sends an action that kicks off the re-provisioning process. This delivers emails back to the manager that was shown and we then have an orphaned identity held in our environment for an extended 150 days.

The goal we are hoping to arrive at is one of two things. If ISC deletes the object that when the severance date arrives and SuccessFactors makes its change that provisioning does not fire. Another approach would be to retain the Severance account in ISC for its life span and then push the account to Archived where it can sit and be deleted in 150 days.

Hello Kristina, what is the actual change(action) SuccessFactors makes on the account when the severance date arrives? And when ISC re-creates that identity from the aggregation, what lifecycle state does it land in?

Hello Harish,

There is an attribute called ‘FutureActions’ that is queueing up events to happen.

{“Actions”: [{“ActionType” : “26”,“ActionReason” : “SEVREDFOR”,“ActionStartDate” : “2026-07-01”,“ActionEndDate” : “2027-06-30”},{“ActionType” : “50”,“ActionReason” : “{redacted}”,“ActionStartDate” : “2027-07-01”,“ActionEndDate” : “9999-12-31”}]}

The lifecyclestate that the account lands into is ‘pendingDeprovisioning’. We have a 7 day hold that the first time an account land into ‘terminated’ they are updated to ‘pendingDeprovisioning’. After which a workflow is triggered to check in 7 days the status of the account before migrating the account to a terminated lifecyclestate if the account has remained in pendingDeprovisioning.

Thanks for sharing that detail, Kristina.

Just to make sure I am on the same page, the identity gets deleted after 150 days, but when the severance date arrives SuccessFactors sends an update via FutureActions, ISC picks it up during aggregation, recreates the identity as if it is new, and it goes back through your normal termination flow triggering the 7-day pendingDeprovisioning workflow & manager notifications again. Is that right?

If that is the case, the main issue may be that this recreated severance identity needs a separate path instead of going back through the normal pendingDeprovisioning flow.

Your first point is accurate for the events that happen, the account terminates and follows our termination procedure, after 150 days the account is wiped from ISC, and when that futureevents updates in aggregation it recreates the identity and follows the terminated process once more before finally going.

With the goal of not having the account being recreated through any aggregations, I am wondering if an approach to have the account remain in an active-dormant state, where no access could be requested on behalf of the account and we would keep all sources on the profile in a deactivated state.

When the date arrives that the severance ends the account is then migrated to an archived state for inactive(long-term) where it can remain for the 150 day duration before finally being left to be purged.

If an account is active in a dormant state where no changes, no entitlements or roles are being added to the profile, would this initiate the inactive timer in SailPoint to lead to purging the account? Or would this 150 day timer begin once the account enters a lifecyclestate that is assigned as Inactive (short-term) or Inactive (long-term)?

Not sure why transforms is tagged here… but this would be something to configure at the source level rather than the identity level. You need to tweak your SuccessFactors filtering.

TIL @sup3rmark has notifications for transforms

Apologies if I had the incorrect tag used, my approach to this problem was through transforms. I did come up with a functioning solution to this through our lifecyclestate management transform.

you can create seperate life cycle states for severence and termination perform, and in each life cycle state, you can configure required provisioning actions.