I need to develop a reactivation use case in SailPoint Non-Employee Risk Management (NERM), and I would like to know whether anyone has implemented a similar scenario.
Currently, SuccessFactors (SSFF) is the authoritative source for internal employees. When an employee leaves the company, their identity in SailPoint Identity Security Cloud (ISC) remains in a Terminated state.
The new NERM use case should cover the following scenario:
The person previously worked as an internal employee.
Their identity already exists in ISC and is currently in a Terminated state.
The same person must later be onboarded as a non-employee through NERM.
The user who launches the reactivation use case would enter the person’s email address.
From NERM, an API call should be made to verify whether the identity already exists in ISC.
The existing identity identifier would be retrieved from that API response.
A NERM account would then be created and correlated to that same identity.
Finally, the email address and other attributes would need to be updated so that the identity represents a non-employee.
The main challenge is that the authoritative source for internal employees uses a different identity profile from the identity profile configured for NERM accounts.
Because of this, I am not sure how to assign the non-employee attribute values to the same existing identity, or how to manage the attribute updates while the identity remains associated with the internal employee identity profile.
Has anyone implemented a similar use case?
Is it possible to correlate the new NERM account to the existing identity and update its attributes with the non-employee values, even though the identity was originally created from a different authoritative source and identity profile?
What approach, configuration, or mechanism would you recommend for this scenario?
It won’t matter if you correlate the NERM account to the SSFF account if it is lower in the profile priority rating. It will remain in an inactive LCS as the SSFF will be the driving force.
Hello Maria. @PhilRawlings1’s suggestion around identity profile priority is the right direction here. In ISC, an identity is associated with exactly one identity profile, the highest-priority one among the authoritative sources where it has an account (docs).
So once NERM aggregates and correlates to the existing identity, SSFF will remain the associated profile as long as it has higher priority, and its LCS mapping will continue to keep the person Terminated while SSFF is driving that value.
If NERM needs to become the associated profile for these identities, one option is to raise the NERM identity profile above SSFF in priority using the Update Identity Profile API. After NERM correlates and ISC processes the identity, the NERM profile’s attribute mappings and LCS should apply.
Profile priority is global, not per identity. Anyone with authoritative accounts in both SSFF and NERM could also shift to the NERM profile under the new priority order, so it’s worth checking the wider impact before making the change. Also, manually setting the LCS isn’t a durable workaround, since a manual LCS only remains until the underlying mapped source value changes (LCS docs).
Yes, it could be achieved. Having identity profile with NERM source would be a good option if you have rehiring scenario only from SF to NERM.
But it is also happening the other way (NERM to SF ) , then i think you should carefully see if you should change the identity profile priorities.
The easiest approach would be to ensure that account is correlated to both the NERM and SF.
Then if the user is sourced from NERM, then ensure that account is deleted from SF or descoped from this aggregation. (if that is possible).
ISC will then assign the lower priority identity profile to the current user as per this documentation link. Please make sure to test this approach in lower environments first.
If the new identity profile already has the higher priority, then deletion from other authoritative source is not required, but i would suggest to keep the standards same for both cases. This will ensure that you have standard process for rehires.
I wanted to ask what would happen in the opposite scenario. If I configure the NERM identity profile with a higher priority, when an identity needs to move back from NERM to the other authoritative source, for example SuccessFactors, would the identity continue using the NERM identity profile because it has a higher priority?
I need to support both scenarios: moving an identity from SuccessFactors to NERM, and also from NERM back to SuccessFactors.
Could this priority configuration cause a conflict in either scenario, or would the identity profile be reassigned correctly based on the corresponding authoritative source?
What I tested was manually uncorrelating the account from the authoritative source that originally created the identity, and then creating the account from NERM. The new NERM account correlates correctly with the existing identity, but the identity still keeps the SuccessFactors identity profile.
In my case, deleting the SuccessFactors account is not an option. However, I could stop reading that account from the source.
My question is: if the account is no longer read by SuccessFactors and, as a result, becomes uncorrelated from the identity, would the identity still keep the SuccessFactors identity profile, just as it did when I manually uncorrelated the account? Or would Identity Security Cloud reevaluate the identity profile and potentially assign the NERM identity profile instead?
I would also like to understand what happens to the identity when SuccessFactors stops reading that account: does the identity remain in ISC with the SuccessFactors identity profile, or is the identity eventually deleted because there is no longer a correlated account from that authoritative source?
Hello Maria. Yes, priority alone will not handle the reverse direction. If both authoritative accounts remain on the identity, the higher-priority profile stays associated, so NERM would continue to win even after SSFF comes back.
For a bidirectional transition, my suggestion is to remove the outgoing authoritative account from ISC through a full aggregation. With Enable Account Deletion turned on and that account no longer returned by the source, ISC removes it, reanalyzes the identity, and if another authoritative account remains, reassigns the identity to that profile (docs). If no other authoritative account is left, ISC attempts to delete the identity during its nightly job.
So for SSFF to NERM, one option is to stop returning that person from the SSFF aggregation rather than deleting the record in SuccessFactors. For NERM to SSFF, archived NERM profiles are not aggregated, and Filter by Status = Active only returns Active and On Leave profiles (NERM docs).
This also lines up with your manual uncorrelation test, where uncorrelating the SSFF account alone did not change the associated profile. It would be worth testing the full transition in a lower environment first.
Yes, if rehiring is possible from both sources then the flow should be like this.
User is already in SF and has associated account in ISC for SF.
You hire the user from NERM. At this stage identity will have account from both sources but SF profile will be maintained as identity profile for the user. This is currently your situation.
Now i suggest, you stop reading the account (exclude from aggregation) from SF and ensure your delete account threshold allows the account removal from ISC source of SF.
This leads to removal of SF account for the identity, and identity will have only one authoritative source i.e NER
Now it mean that identity profile will be shifted to next higher priority identity profile for the identity i.e NERM for your case.
This should then keep all the roles which the user had assigned earlier or other links as well unless birthright roles are removed based on some criteria.
Then it should allow you to rehire.
For the other way around, when hiring happens from NERM to SF. All the steps will remain same. The only difference would be that you do not need to remove the account or unread the account from NERM. If SF profile has higher priority, then identity profile will automatically shift to SF.
Note that all above scenarion, I have assumed that SF identity profile has higher priority. If your NERM identity profile has higher priority, then the steps remains same but in other way around as described above.
For your above question, you should not uncorrelate the account but rather remove the account from ISC knowlegde as it is authoritative source account.
I will also recommend you testing it in lower environment because planning the cutover in Prod tenant.
It is possible but you need to enter the same user email or sam account name for correlation.Also your nerm profile should be higher in priority to the sap profile.which will then look for nerm profile as priority
