This blog post introduces you to the recently published SuccessFactors Implementation Design Principle document: SAP SuccessFactors Onboarding: External HRIS Integration (SAP ERP HCM)
SAP SuccessFactors Onboarding solution integrates natively with SAP SuccessFactors Employee Central, while it’s being used as a Core HR. This has been considered as the preferred setup in many customer situations. However, some customers still leverage SAP ERP HCM as the system of record for employee data maintenance. For these customers, the requirement is to integrate SAP SuccessFactors Onboarding with SAP ERP HCM directly as a core HR solution.
This integration has not been delivered as a pre-packaged solution and therefore customers must build a custom integration.
In many customer landscapes, EC is the source of record for some countries and ERP is the source of record in other countries, and such a setup is often known as a Side-by-Side deployment. With the help of this document, customers can build an end-to-end automated solution alongside other SAP standard solutions (say, Side by Side Deployment) in the existing landscape.
There are some details in the blog that are very specific to SAP ERP HCM, but a similar approach can be taken by customers using other external HRIS solution (non-SAP) that needs to integrate with SAP SuccessFactors Onboarding solution.
SAP SuccessFactors Onboarding triggered by SAP SuccessFactors Recruiting Management
This is the most common/standard approach being adopted by many of our customers. With this, an administrator initiates onboarding with SuccessFactors Recruiting at the end of the recruitment process. The new hire gets created into SuccessFactors Onboarding with the data that is mapped from recruitment to Onboarding. During onboarding, personal and additional data is collected. After the completion of the data collection, there could be an optional signature step. Upon completion of the data collection and the “signature” step, the overall onboarding process is completed. The data collected in onboarding can be exported/transferred to SAP HCM
The exported information must be used by the External HRIS system to update an employee’s master data and complete a new hire in External HRIS (SAP ERP HCM) system directly. Once a hire has completed in the external HRIS system, SAP SuccessFactors Onboarding must be notified of the same. This marks Onboarding hiring status to ‘Hired’.
In case, there is a restart of the Onboarding process, it generates a new event with Onboarding Stable ID in the SAP SuccessFactors Onboarding system. For specific scenarios, when restart happens after the new hire data is exported to the external HRIS, then the external system listens and reacts to the event. The newly started process goes through the Onboarding steps, and when the new hire is in Ready-to-Hire state, the external HRIS imports the new hire data once again. At this stage, the Onboarding Stable ID, which is present in the export file, acts as an identifier for the previous Process ID and the new Process ID of the new hire data.
Ingredients of setting up External HRIS integration (SAP ERP HCM)
Mini EC setup
Even though a customer is not using SAP SuccessFactors Employee Central as a core HR in an external HRIS scenario, it would still require a miniature version of the Employee Central system to be configured This means, minimum set of entities namely Basic user, Biographical Information, Employment Details, Personal Information, & Job Information will be required to replicate employee data from external HRIS. Please note, this will also need Foundation objects to be configured and imported into the Employee Central system to support the loading of mini master data for all employees there.
For purely Onboarding purposes, the structure is not very important, what is more, important are the employees who are part of the Onboarding process and can be identified somewhere in the organization structure. All these organizational objects are required to complete the employee data, especially the job information portlet. The legal entity is mandatory, all the other objects are based on the customer’s organizational management design.
Other objects such as position, Job classification can be considered but are optional. Recommendation is not to get all the foundation data just the minimum that is required to complete the hire and also indicate changes like transfer and termination. The data can be used as criteria to create responsible groups.
The following portlets (except Email Information) cover the mini master data maintenance into Employee Central. Alongside these, the Email Information portlet should also be filled in as well, which allows the responsible Onboarding participants to receive timely notifications
|User Data File /Employee Profile||Basic user file or Employee Profile||User ID is the key field|
|Personal Information||Personal Information that can change over time like Marital Status, Gender, Name, etc.||Person ID External is the key|
|Biographical Information||Personal Information that does not change like Date of Birth & Employee ID||Person ID External is the key|
|Employment Details||Records data specific to the employee’s employment with the company typically dates such as Hire Date etc.||User ID is the key field|
|Job Information||Allows effective-dated tracking of all Job changes of the employee||User ID is the key field|
Email Information such as Hire Date etc.
|Allows recording of multiple email types and addresses||Person ID External is the key|
Onboarding process participants
All other portlets in Employee Central are purely optional and may be required based upon the customer’s requirement for data maintenance. Please do note that the above portlets are only required to capture Managers, Hiring Managers, etc. who are an integral part of the Onboarding process.
Other setup details for mini EC
Please refer the document for more details on the EC min setup
There are multiple jobs, which are linked with end to end running of an Onboarding process into the system. This section provides a high-level overview of the jobs involved and provides more details around the behavior with specific examples.
This is the job that converts the Active External user to an Active Internal user, on the start date of a new hire. And, once this run has been successful, new hires can log in to the SAP SuccessFactors application as a normal employee. There are predefined parameters (say, Business Start Hour) that needs to be chosen carefully based upon the business needs.
This job parameter checks for the external user’s start time in their local time zone. The field for determining the time zone is based on the location of the user. (the field location in job information is the source for this).
For example, if the parameter has been set to 8 A.M. and the provisioning job runs after 8 A.M German local times, all such new hires located in Germany will be converted to employees.
Let’s understand this more via varied scenarios covered in the table below, which illustrates the behavior of the Job-based upon the server location and the Business Start Hour of the new hire’s joining location.
|Server Location||Germany – Time Zone (CET)|
|Business Start Hour||5:00 AM|
|Country of a New Hire||Time||Germany||India||Australia||USA|
|Job Run Time||5:00 AM|
|Local Time during the Job Run||5:00 AM||8:30 AM||1:00 PM||
(One day before hire date)
|Job Run Time||8:00 AM|
|Local Time during the Job Run||8:00 AM||11 30:AM||4:00 PM||2:00 AM|
|Job Run Time||11:00 AM|
|Local Time during the Job Run||11:00 AM||2 30:PM||4:00 PM||5:00 AM|
It assumes that the job hasn’t been run three times explicitly. However, it just depicts the independent scenarios and their respective results when the job runs either at 5 AM, 8 AM, or 11 AM
Key decision factors, which one needs to be aware of while setting up such jobs –
Do customers have to run this job multiple times?
Yes, customers may have to configure multiple instances of the same job, especially if one has multiple shifts/multiple countries where onboarding has been implemented.
What should be the typical frequency of such background jobs?
We would need to run the job more frequently to cover off different time zones and hence avoiding a long wait/outage for user access in the landscape.
What should be the value of the first job’s business start hour?
We can keep the Business Start hour just after midnight or 1:00 AM so that new job runs after this period will include those external users who would be starting on that day.
HRIS sync Job
The purpose of this background job is to exchange the data between SuccessFactors Employee Central and the HXM Core to allow consumption of data by other SuccessFactors modules. It typically looks for changes made in Employee Central data at a predefined schedule and made updates to the user table. The mapping has been the same, to what’s been used with Employee Central (and defined with the relevant data models).
This job needs to be set up even in the absence of a full EC implantation. Employee Profile is the source of employee data for all the talent modules and platforms. This needs to be running even for consumers of the data like the Role-Based Permission.
With SAP SuccessFactors Onboarding, this job is also being called synchronously during New Hire Data Review, Personnel Data Collection Steps, etc.
Identifiers generated in SAP SuccessFactors
With SAP SuccessFactors Onboarding, a user ID has been generated within the system itself as soon as Onboarding has been initiated from the SAP SuccessFactors Recruiting. There are broadly two different ways, which generate these employee identifiers in the system –
- Use “Next Person ID Assigned” under Company System and Logo Settings which provides a running global sequence number.
- Use a business rule, that allows a custom User ID and Employee ID format defined based upon specific conditions.
Overview of the process flow
With the scenario highlighted above, it has been assumed that User ID/Person-ID external has been generated within the SAP SuccessFactors Onboarding, and replication to SAP ERP HCM takes place once the overall Onboarding process has been completed.
This section covers the necessary detailed process steps, which need to be in place for the implementation of the relevant business process in a customer landscape.
1.Offer Acceptance/Ready To Hire
It’s the final step in SAP SuccessFactors Recruiting system, where an offer has been accepted by the candidate and is ready to be onboarded into the SAP SuccessFactors Onboarding system. At this stage, the candidate only holds a unique identifier ‘Candidate ID’ with a hiring status “Ready to hire” within Recruiting Management system while there is no corresponding UserID/Employee ID generated yet within SAP SuccessFactors.
This is triggered from Recruiting Management system, where an administrator chooses the ‘Initiate Onboarding’ option while a candidate is already there in talent pipeline status ‘Ready to Hire’. As soon as Onboarding has been successfully initiated, the UserID and Person-ID-External are created within the Onboarding system and the rest of the regular onboarding process follows based upon predefined process variant in the system.
3.Complete Onboarding process
Based upon the Process Variant definition, Onboarding steps like the New Hire Data Review, Personal Data Collection, Additional Data Collection, Signature, etc. will be executed within the system. Completion of these steps results in actual completion of the onboarding process, which also means that new hire is now eligible to be hired within the Core HR system. A system field that represents this, is the “Hire Status” defined with the ONB2Process object and been set to value “Ready to Hire” as soon as the Onboarding process has been completed.
4.Transfer Onboarding data to SAP ERP HCM
This process is triggered via an IS event “External User Eligible for Hire”, which has been raised due to a change in the ‘Hire Status’ value. A custom solution on SAP ERP HCM or any other external HRIS system listens to this event and executes the rest of the automated process for employee data update. Such custom solutions to export relevant data can be either a completely middleware-based orchestrated solution or a simpler file-based approach with the Integration Center.
Having this in place, all the necessary personnel data and any additional data captured during the Onboarding period would be used to update the respective HR Infotypes in the system, and eventually, an employee has been hired in the SAP system. However, please note that this hire may not be complete as certain tax and social insurance data will be captured in SAP HCM directly while this is not available yet from Onboarding.
The key consideration which needs to be there at this point is around the number range of employees on the SAP ERP HCM side. Technically, it can be an Internal or External Number range, and based upon the option chosen, respective new IDs will be created within the system.
Let’s say if it has been set to an external number range, then existing unique identifiers(User Id and Person Id external) from the SAP Onboarding system will be used to create a PERNR in the system. However, if it’s an internal number range, then a new employee number (PERNR) will be created directly on the SAP ERP HCM system and eventually needs a mapping table that stores the relationship between the UserID created from the Onboarding side and the new one leveraged by the SAP ERP HCM.
Restrict the New hire PERNR from replication
Although the data captured in onboarding is used to create a PERNR in SAP ERP HCM, Tax and social insurance data needs to be maintained the system till that time this PERNR should not be replicated back to EC mini. Hence, there is a need them from the scope of the regular Side-By-Side replication package running already.
To make sure that this check has been in place, one should take care of the below conditions which helps to determine if a PERNR yet belongs to a new hire than an actual employee.
- Include records only from the hire date. Any run before the hire date, would results in an error
as the standard User object wouldn’t get updated for ‘external’ status. Once an external user has been converted into an internal on day one via a provisioning job, the actual User object can be updated on SuccessFactors with standard integration.
- Exclude pre-hire candidates from the replication scope and can be differentiated by either preliminary
approaches listed here.
- Maintain a separate Action Reason for pre-hire with an existing Hire Action.
- Maintain a new custom field (Say, isOnboardee) with any of the relevant Info types in the system
These approaches should be assessed by the customer based upon their landscape. Technically, one can use the standard BAdI program: ES_ECPAO_EMP_VALIDITY_TAB, with an export parameter ‘EV_IS_EC_MASTER’ set to ‘true’ and it eventually helps to exclude such new hire PERNRs based upon any of similar conditions.
5.Mapping – Onboarding UserID with SAP PERNR
As highlighted above, it’s important to associate the Onboarding UserID with the SAP ERP HCM employee number when an internal number range is being used by the customers. One can build a custom mapping table to map the ERP key (PERNR) with the corresponding EC keys such as UserID and Person ID external etc. Key considerations here are –
- If a user has been flagged as an New hire, the customer should populate the UserID, Person ID external, etc. using the BAdI – EX_ECPAO_EMP_USYID_PRN_UNM_MAP into the custom table.
- SBS program needs to handle/read the custom mapping table at the time of the actual Side-By-Side run for Onboarding cases to refer to the right employee identifiers, which should be replicated to Employee Central. For non-Onboarding cases, a customer-specific condition can be defined within the method – IF_ECPAO_EMP_ USYID_PRN_UNM_MAP~GET_PERSONID (each identifier has a different method)to regulate the employee id replication to the Employee Central.
- It’s recommended to update this custom table before the Side-By-Side run, else a standard Side by Sidereplication assumes that no such person is existing already in the system and hence will create a new user ID for the same person in Employee Central while replicating updated data from SAP ERP HCM.
6.Complete Hiring in SAP ERP
Once a custom solution has updated the infotypes on the SAP ERP HCM with the Onboarding data, this step covers the additional data requirement which hasn’t been captured during the Onboarding process itself and hence needs direct maintenance (say, for Tax, Social Insurance, other similar data, etc.) on the ERP system.
Such a process is being typically done by system administrators and completes the hiring process on SAP ERP once it’s been maintained well in the system.
7.Notify/Update Onboarding process
This step updates the Onboarding process about the completion of the hiring process in the external HRIS. Please use the API ‘updateFromExternalHrisONB’ to mark hireStatus as “HIRED” on the Onboarding application. Also, please note that the “hiringNotCompleted” flag has been automatically updated to ‘false’ for respective employment once this update has been successful.
8.Convert External User to an Internal User
With SAP SuccessFactors Onboarding, a background job runs on the hire date of an employee which basically converts an external user to an internal user. Please refer to section 6.1.2 for more details about the job and its behavior in the system for global landscapes.
9.Employee Replication – Side-By-Side Integration
It’s a standard packaged integration that has been typically leveraged for the Side-By-Side deployment model for replicating data from SAP ERP HCM to SAP SuccessFactors Employee Central, which can be reused here for data transfer of regular employees. Please refer to the guide, for more details about this standard solution. The data transfer for the new hire will happen on or after the hire date.
One should take care of necessary customizing settings under “Define Employee Data Settings for Employee Central (View V_ECPAO_CMPNY_EE)” to ensure the right mappings are in place for UserID, Personal ID External, etc. in the system.
Please use the BAdI EX_ECPAO_EMP_USYID_PRN_UNM_MAP to map the Employee Central fields user_id, username, and person_id_external (for employees). With this, one can extract the data for the user_id, username, person_id_external, and external code fields from sources other than infotype fields. So, the value for these fields should be read from the custom mapping table (covered in step 5) for the new hires turned into employees and making sure that a new user hasn’t been created for them into Employee Central.
For other business scenarios please refer the document for more details.
Other scenarios include
Pre-hire in SAP ERP HCM, before Onboarding trigger
Source of Employee Number in an external 3rd party system
I would like to thank Anoop Garg who co-authored this document.
Please read the entire document for more details and insights. Please use the comment section to let us know if you have more questions and other scenarios that are not covered in the document.