Contractor to Employee Conversion in SailPoint IdentityNow – Explained with Real-Time Example

Introduction Of Contractor to Employee Conversion in SailPoint IdentityNow

In most organizations, it is common for contractors to eventually become full-time employees. While this is a straightforward HR process, it can get complicated in Identity and Access Management (IAM).

If not handled properly, a conversion can result in:

• Duplicate identities

• Multiple accounts for the same person

• Access not being updated correctly

SailPoint IdentityNow (IDN) provides a clean way to handle this conversion without deleting accounts or making complex transform changes. Let’s walk through the process step by step, using a real-time example.

The Challenge

• Contractors initially join with a ContractorID.

• When converted, HR assigns a new EmployeeID.

• Both IDs may exist in systems like Active Directory, ServiceNow, etc.

• We need a way to flip the identity from “Contractor” to “Employee” in SailPoint, while keeping accounts linked and attributes updated.

The Approach

Here’s how you can configure SailPoint to handle this scenario:

1. Add Contractor ID to Employee Record

• Store the ContractorID in the new employee record in SuccessFactors (or your HR system).

• This acts as a bridge between the old contractor identity and the new employee identity.

2. Set Profile Precedence

• Make sure the Employee ID profile has higher precedence than Contractor ID.

• On conversion day, SailPoint automatically flips the profile from Contractor → Employee.

• This flip happens even if the employee account is currently disabled.

3. Control Timing with XPath

• In SuccessFactors, use XPath logic to ensure ContractorID only appears on the employee record from the employee’s start date.

• This prevents premature correlations before the employee officially starts.

4. Configure Account Correlation

• In each target system (AD, ServiceNow, etc.):

  1. Add a correlation rule that maps Identity Attribute: ContractorID → Account Attribute: native ID (e.g., empid/keyid).

• This ensures that existing contractor accounts continue to correlate with the new employee identity.

5. Sync Identity Attributes

• Certain attributes need to be pushed to target accounts when the conversion happens.

• Example:

  1. employeeType = contractor → employee

  2. employeeNumber updates to match new EmployeeID

• Configure Attribute Sync to push these updates to connected systems.

Real-Time Example

Let’s take John Doe as an example.

Before Conversion (Contractor)

• SuccessFactors:

  1. ContractorID = C12345

  2. EmployeeType = contractor

• Active Directory (AD):

  1. Username = john.doe

  2. Linked via ContractorID C12345

Conversion Day

• SuccessFactors updates:

  1. EmployeeID = E98765

  2. EmployeeType = employee

  3. ContractorID = C12345 (carried over for correlation)

• SailPoint checks profile precedence:

  1. Employee profile > Contractor profile

  2. John’s identity flips to Employee

After Conversion (Employee)

• SailPoint IdentityNow:

  1. Identity profile: Employee

  2. EmployeeID = E98765

  3. ContractorID = C12345 (used for correlation)

• Active Directory:

  1. Still the same account → john.doe

  2. Attribute employeeType updated from contractor → employee

  3. No duplicate account created

Conclusion

• John continues using his same AD account (john.doe).

• His identity in SailPoint is now Employee.

• Attributes in all target systems are updated.

• No duplicate identities or manual cleanup required.