With every SuccessFactors implementation one of the topics that needs very meticulous planning and design is the mapping of Employee IDs.
Employee Identifiers play a key role in an integrated system landscape. Different requirements such as multiple employments, global mobility, single or multiple employee talent profiles adds complexity to the landscape. This blog provides an overview of the the key employee identifiers existent in EC, Talent Suite and SAP HCM and how these impact requirements related to multiple employment and job/talent history. It also provides recommendations for mapping the identifiers for both existing talent customers implementing EC as well as for green field EC implementations.
In order to provide more insight and to state a clear scenario-based recommendation, we released an “Implementation Design Principle” covering the subject. You can access it as a customer here, and as an implementation partner here. Important excerpts from the document can be read below.
Green Field Customers
Customers who will implement SuccessFactors for the first time, while they have always been using SAP on-premise as an HR core will need to align the employee IDs between different data models of SuccessFactors and SAP on-premise. For example: In Employee Central it is possible to have another record against the same employment (same UserID) during an internal transfer of an employee whereas a standard implementation in SAP ERP will result in creation of new personnel number during international transfer.
Existing SuccessFactors Talent Suite Customers
When SuccessFactors is used only as a Talent Suite (without employee Central) then all the data within SuccessFactors Employee Profile is non-effective dated, and only a single UserID will exist per each person in the Instance. This allows that only a single talent history per employee will be present at a SuccessFactors BizX instance.
Employee Central provides the option to customers to have multiple UserIDs per Employee in an instance. Every new employment will then create a new UserID in SuccessFactors instance . Therefore, there is a possibility to have a multiple instances of Talent history per employee.
Basics and Design Approach
This section provides some basic information around important employee identifiers used in SuccessFactors and attempts to provide more clear view as to how employee identifiers are managed in SuccessFactors. The most relevant employee identifiers listed by the following table:
Table 1: Identifiers
Employments and UserIDs in SuccessFactors
When Employee Central is active or not implemented at a customer’s BizX Instance (for example, in the case of a Customer deploying modules like Performance and Goals, Learning, etc), the central repository for employee data in the BizX Instance is the so-called Employee-Profile (EP). That means, for non-Employee Central customers, who are using Talent modules in BizX the employee hiring process will take place outside of BizX instance. Once the hiring is complete in the source system, the employee data is replicated into SuccessFactors (preferably by means of an available Integration Interface). In this scenario, only the Employee Profile fields “UserID” and “Username” are relevant identifiers for employees within the BizX Instance. In other words, for BizX customers without Employee Central, an employee will always be identified (in BizX) by a single UserID and a single Username.
When Employee Central is implemented and live in the customer’s BizX instance, during a new hire process in Employee Central, all the IDs above mentioned are generated, including the PersonID External. By default, UserID is auto-generated and Username and PersonIDExternal are copied from UserID. Therefore, all the three fields have the same value after new hire process has completed, though this default behavior can be changed via Business Rules, so that each one of them can get a specific value which can be different from each other. With Employee Central, an employee can have multiple instances of UserID, Username but only one single instance of PersonIDExternal. With every new employment for a Person, a new instance of UserID and Username are created. The following table lists some of the scenarios during which new UserIDs are created.
Table 2: Employments
Data Model and APIs
Figure below shows internal SuccessFactors Data Model (with Tables) used for SuccessFactors Employee Identifiers.
Note: The table structure below is subject to change anytime and is shown for better understanding. The identifiers PERSON_ID and EMPLOYMENT_ID are internal IDs within SuccessFactors. The only IDs relevant and available externally are:
- USERS_SYS_ID (SuccessFactors UserID),
- USERS_SYS_USERNAME (SuccessFactors User Name)
- PERSON_ID_EXTERNAL (SuccessFactors PersonIDExternal – Relevant only when Employee Central is part of the Suite)
Figure 1: SuccessFactors Data Model
Disclaimer: The figure above is only a pictorial representation of backend SuccessFactors tables. Figure above should not be interpreted as an actual database structure.
In a SuccessFactors environment (BizX instance) without EC, the table USERS_SYS_INFO, responsible for driving the Employee Profile data, is the only relevant one in terms of storing employee identifiers. However, the user-related entries in Employee Central tables EMP_EMPLOYMENT_INFO and PER_PERSON are automatically created whenever new entries are added to USER_SYS_INFO, even if the customer has not even implemented nor have licenses for Employee Central yet.
In a SuccessFactors environment with EC, with every new employment for an already existing Person in the system, new records are created in tables: EMP_EMPLOYMENT_INFO, USERS_SYS_INFO. With every new Person to be added to the system, table PER_PERSON is updated.
In a SuccessFactors environment with EC, minimum of following entities (upload templates/APIs) are required to create an employee:
In a SuccessFactors environment (BizX instance) without EC, only “User” entity is needed for user creation.
HRIS Synchronization Job
In a SuccessFactors environment (BizX instance) without EC, Employee Profile (EP) is updated directly during user updates or is being fed with data from the masterdata source system via an integration interface.
For Employee Central customers, EP is fed with data from EC Database tables via the use of BizX “HRIS Synchronization job”.
Employee Data Models in SuccessFactors EC and SAP ERP HCM
This section provides a comparison between data model of SuccessFactors EC and SAP ERP HCM. Note: The information provided in this section is for reference purposes only. Please refer the relevant implementation guides for detailed explanation.
Employee Central Data Model is shown below.
Figure 2: SuccessFactors Data Model – Source : Standard Integration Guide
SAP ERP Data model can be depicted below:Figure 3: SAP ERP Data Model- Source : Standard Integration Guide
Usage of Infotype 0709 (Person ID) in EC-ERP Productized Integrations
In a standalone SAP ERP system, Infotype 0709 is relevant only when “Management of Global Employees” module is activated in SAP ERP. Please note that in SAP ERP, following options exist for the customer, for the Person ID generation rule:
- Same as the Central Person Object (CP)
- Same as the number of the first personnel assignment (PERNR)
- Same as the person ID stored in the Personal Data infotype (0002), field PERID.
- Any customer-determined value, which can be achieved with Badi HR_CE_PERSONID_EXT
In BIB (Business Integration Builder) based productized integrations, customers need to explicitly configure and perform relevant field mapping in order to replicate infotype 0709 from EC to SAP ERP. Infotype 0709 is not a mandatory infotype required for the replication interface to work. In the legacy (non-BIB based), productized integrations, IT0709 is auto-updated with the value of SuccessFactors EC PersonIDExternal field.
Mapping of EC Identifiers with SAP ERP HCM involving Infotype 0709 (Person ID)
In the figure below, you will find a diagram that illustrates the mapping and flows of Person and employments/assignments between EC and SAP ERP as per the productized EC-ERP integrations.
Figure 4: Replication with IT0709
As shown in the figure above, during migration to SuccessFactors EC (see arrows 1, 2 and 3), SAP ERP personnel number is mapped to SuccessFactors UserID and IT0709 is mapped to EC PersonID External. See employment 1, in the figure above. During migration the employee key mapping table needs to be updated (before EC to SAP ERP replication is initiated) with the details from employment 1. The CP-P (SAP ERP Central Person – SAP ERP Personnel number) relationship is expected to exist in the system.
For replication (EC to SAP ERP) same mapping is utilized (see arrows 4, 5,6 and 7). In other words, SuccessFactors UserID is replicated to SAP ERP Personnel number and SuccessFactors PersonID External is replicated to IT0709. During replication, the employee key mapping table is updated with a new entry and also the CP-P is also created accordingly. See employment 2, in the figure above.
Mapping of EC Identifiers with SAP ERP HCM excluding Infotype 0709 (Person ID)
In the figure below, you will find a diagram that illustrates an alternative (but also standard) version of the mappings and flows, for the integration between EC and SAP ERP HCM identifiers. This version does not include Infotype 0709 in the mappings.
Figure 5: Replication without IT0709
As shown in the figure above, during migration to SuccessFactors EC (see arrows 1, 2 and 3), SAP ERP personnel number is mapped to SuccessFactors UserID and SAP ERP Central Person object is mapped to EC PersonID External. See employment 1, in the figure above. During migration the employee key mapping table needs to be updated (before EC to SAP ERP replication is initiated) with the details from employment 1. The CP-P (SAP ERP Central Person – SAP ERP Personnel number) relationship is expected to exist in the system.
For replication (EC to SAP ERP) same mapping is utilized (see arrows 4, 5, and 6). In other words, SuccessFactors UserID is replicated to SAP ERP Personnel number. During replication, the employee key mapping table is updated with a new entry and also the CP-P is also created accordingly. See employment 2, in the figure above.
We encourage you to read this and other IDPs and bring your comments and ideas / feedback to us either by commenting on this blog or by contacting us at SAPSuccessFactorsIDPDoc@sap.com
We are planning to continuously publish more documents addressing relevant topics, hence it is worth to drop by regularly and bookmark the links!