Learn about SAP SuccessFactors Employee Central data provisioning
This table describes how specific data types are processed when SAP SuccessFactors Employee Central is integrated with Okta.
|Multiple Job Assignments||
If you have employees with multiple job assignments (either with Global Assignment or with Concurrent Assignment), this is how they are processed by Okta:
Global Assignments are prefixed with "person___employment_information_GA1___". For example: "person___employment_information_GA1___job_information___job_title"
Standard Assignments are prefixed with "person___employment_information_ST1___job_information". For example: "person___employment_information_GA1___job_information___job_title". ST1/ST2 define the employment_information.employment_id value. For example: "employment_information.employment_id=123" is processed as "ST1" and "employment_information.employment_id=456" is processed as ST2.
A user's status is derived from the Job Information entity in Employee Central.
If a user's job_information.emplStatus == "A", the user is treated as active in Okta.
If a user's status is not active in the Job Information entity, Okta makes a second check on the user's job_information.start_date).
If the user's start date falls in the preHire Interval period, the user is identified as an active pre-hired user in Okta. Okta selects the earliest value job_information record for each user, and performs the following check: "now > startDate > now + preHireInterval" — if the condition is true, the user is treated as active.
If a user is inactive and they do not pass pre-hire verification, a post-termination verification is performed. Okta selects the most recent *___job_information___start_date (termination start date) value and verifies it against "inactiveStartDate < (now - postTerminationInterval)".
If user fails all verification, they are identified as inactive and are not imported into Okta.
This diagram illustrates the Okta user status verification workflow:
The SuccessFactors Integration supports Multiple Active User Statuses where an admin can choose different user statuses to be treated as active in Okta. The default status will always be Active even if an admin does not choose anything. For example, Cathy is currently on paid-leave but she still wants to access her apps in Okta. With this feature, if the admin chooses paid-leave as active user status, she will be able to access the apps.
You select those User Statuses that you want to consider as Active when configuring SucessFactors provisioning (Provisioning tab > To Okta > General section, Active User Statuses field).
|Phone and Email||
For both phone and email, the entity marked as "isPrimary = true" is mapped to the Okta user profile. If write-back functionality is enabled, Okta writes back to the phone and email fields and sets the type as Primary.
Due to API limitations, Okta email addresses can only be updated for users with a configured email marked as primary and with an active email type (usually "Business" type).
|Contractor to Full Time Employee Conversion||
In SAP SuccessFactors Employee Central, contractor to full time employee conversion is treated as a termination of the contingent worker, and a new hire of a full time employee.
When the contingent worker is terminated in SAP SuccessFactors Employee Central, the user is deactivated in Okta when user data is next synchronized, unless post termination is enabled. When the user is added as a full time employee in SAP SuccessFactors Employee Central, their data is imported into Okta, and the import matching rules are used to match the newly created SAP SuccessFactors Employee Central full time employee to the existing deactivated Okta user. However, you will need to manually reactivate the user. Automated reactivation using import matching rules is not supported.