Contractor to employee conversion in ISC

In a contractor to employee conversion. The contractors and employees have different sources. The Employee has a higher priority source.

In this case, how would the correlation of target systems play out after the conversion. Should I consider re-writing any transforms?

Can someone please explain?

Hi @PawanKalyan

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.

  1. Set Source Precedence
    Go to Identity Configuration → Source Precedence and drag EmployeeSource above ContractorSource. Now ISC will prefer employee data whenever there’s overlap.

  2. Use an Attribute-Based Transform
    Instead of checking source names, switch your transform to test on an employmentType attribute. For example script:

// contractor vs. employee transform
if (identity.employmentType === "Contractor") {
  // contractor logic
  identity.addEntitlement("ContractorLaptopAccess");
  identity.title = "Contractor";
} else {
  // employee logic
  identity.addEntitlement("EmployeeVPNAccess");
  identity.title = identity.jobTitle;
}
// keep common fields
identity.workEmail = identity.email;

  1. This way, after conversion ISC simply flips employmentType to “Employee” and applies the right branch automatically.

  2. 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.

  3. 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.

  4. 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.

1 Like

Hi @PawanKalyan,

Here is what you can do.

As @selvasanthosh stated in his first point,

  1. Add to the employee record a contractor ID value(unique identifier of the contractor)
    1. We use this to correlate the employee account to the current contractor identity.
  2. Set the presedence - Have the employee id profile on top of the contractor id profile
  3. On the day of convertion, since the employee id profile has higher preference, the ID profile flip happens
    1. Note that filp of the id profile happens, even in the case of disabled employee account
    2. 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
  4. For each target source that can be correlated to contractor
    1. Go to account correlation
    2. Add another mapping: identity attribute: contractorID, account attribute:unique native identity(ex: empid/keyid)
    3. Go to attribute sync and push those identity attributes that are unique to employee(employee type, employee number, etc.)
      1. Go to create profile and see which identity attributes are being used to create the account

        1. 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.

hi @PawanKalyan

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?

Thanks in advance