Here’s a straightforward way to handle a contractor-to-employee conversion in SailPoint Identity Security Cloud so that you end up with one unified identity and the correct entitlement logic—no massive rewrites required.
Set Source Precedence
Go to Identity Configuration → Source Precedence and drag EmployeeSource above ContractorSource. Now ISC will prefer employee data whenever there’s overlap.
Use an Attribute-Based Transform
Instead of checking source names, switch your transform to test on an employmentType attribute. For example script:
This way, after conversion ISC simply flips employmentType to “Employee” and applies the right branch automatically.
Verify Correlation Keys
In Identity Configuration → Correlation Rules, make sure your join keys (e.g., email, employeeID) are identical in both sources. No changes here if they already match.
Test the Flow
Run reconciliation for both sources.
Confirm that a single identity now has employmentType = "Employee".
Check that “EmployeeVPNAccess” shows up, and “ContractorLaptopAccess” is no longer applied.
Clean Up Legacy Logic
Remove or archive any old transforms that directly reference ContractorSource by name so you don’t have conflicting rules later.
That’s it! By relying on source precedence plus an attribute-driven transform, ISC will automatically handle the conversion and downstream provisioning without a ton of extra work.
Add to the employee record a contractor ID value(unique identifier of the contractor)
We use this to correlate the employee account to the current contractor identity.
Set the presedence - Have the employee id profile on top of the contractor id profile
On the day of convertion, since the employee id profile has higher preference, the ID profile flip happens
Note that filp of the id profile happens, even in the case of disabled employee account
Since our employee source is success factors we used XPath logic, to ensure that the contractor id on the employee account be present only on the employee start date even though the account is present before the employee start date
For each target source that can be correlated to contractor
Go to attribute sync and push those identity attributes that are unique to employee(employee type, employee number, etc.)
Go to create profile and see which identity attributes are being used to create the account
Explanation: lets say employeeType attribute having its value as “contractor” was used in creating account on this target source. This means when the flip happens, this employeeType will change to “employee”(check transforms or values on both id profiles). So, since this value changes, this value needs to be updated on the target source account as well. So, this needs to be pushed
So, in this way, even if the contractor account is not deleted on the source, it will continue to correlate to this comverted employee identity and without using any modifications to transforms we can achieve the conversion.
since you marked my post as solution, is this the way you implemented. Can you share more details about your design and if there is any difference between yours and mine?