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.
| Data Type | Description |
|---|---|
| Multiple Job Assignments | If you have employees with multiple job assignments (either with Global Assignment or with Concurrent Assignment), Okta processes them in this way: 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. |
| User Status | 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 isn't 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 don't 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 a user fails all verification, they're identified as inactive and aren't imported into Okta. The following diagram illustrates the workflow for Okta user status verification:
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 is always Active. For example, Cathy is on paid-leave and wants to access her apps in Okta. With this feature, if paid-leave is set as an active user status, she can access her apps. You select the user statuses that you want to consider as Active when configuring SucessFactors provisioning. You can do this in your SuccessFactors integration by going to the Provisioning tab, clicking To Okta, and then editing the General section. This allows you to set which status is active in Active User Statuses. Notes:
|
| 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, you can only update Okta email addresses 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. This occurs when user data is next synchronized, unless you enable post-termination. When the user is added as a full-time employee in SAP SuccessFactors Employee Central, their data is imported into Okta. 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 need to manually reactivate the user. Automated reactivation using import matching rules isn't supported. |
