Like any integrated system, customers using both SuccessFactors Recruiting and SuccessFactors Employee Central can have seamless integration between the applications. Application, Requisition, Offer, and Candidate data from Recruiting can be mapped to Employee Central fields in the New Hire process so that data is pre-filled for the end user. In this blog, we’ll go through the steps to configure the mapping and how to operate the integration.

Prerequisites

Before mapping the fields, the Hirable status needs to be added into the Base list of statuses in Recruiting. The steps for this can be found in the SuccessFactors Recruiting Management Implementation Guide on SAP Service Marketplace in the Hire & Onboard section, in sub-section 8.1.1 Employee Central (RCM to EC Integration).

The consultant(s) doing the mapping should be familiar with the Employee Central data model and/or the Recruiting data model.

Whoever will perform the hire in Employee Central needs to have permission to access the Manage Pending Hires transaction.

The mapping template

The process of hiring an employee in Employee Central that has originated in Recruiting is called Candidate to Employee Conversion. The mapping of the Recruiting fields that need to be used in the New Hire transaction in Employee Central is made in the transformation XML template, which can be downloaded from Provisioning using the Import/Export Candidate to employee integration template option under the Managing Recruiting heading, as seen below:

The transformation template is made up of one main XML element (<object-mappings>), which has two child elements that represent the two major sections of the template. The <object-mappings> element has 3 mandatory attributes that must be applied. It should look like this:

The two child elements within the <object-mappings> element are:

• <entity-mapping-details>: this element is for mapping the fields
• <role-mapping>: this element is for mapping roles

The <entity-mapping-details> element contains a number of <mapping-attribute> elements that represent each mapping. We’ll look at these shortly. The <role-mapping> element contains <target-roles> and <manager-roles> elements, which we’ll discuss a little later in this blog.

A basic example of the transformation XML can be seen here:

Configuring the mapping

The mapping itself is fairly straightforward. There is an element called <mapping-attribute> that has two child elements: <source> and <target>. Each element represents one field mapping. The child elements have attributes to define:

• <source>: source field and source element (Job Requisition, Application, or Offer Letter)
• <target>: target HRIS element and field

This is formatted as such:

To look at a practical example, let’s look at the mapping of surname:

This tells us that the Recruiting fields is lastName and it comes from the Application (application). It will be mapped to the Employee Central field last-name that is in the personalInfo HRIS element (Personal Information portlet on the Personal Information screen).

The three entity types used for the <source> entity-type attribute are:

• Application: application
• Job Requisition: jobrequisition
• Offer Letter: offerletter

The following target HRIS elements can be mapped to:

• personalInfo
• personInfo (only field date_of_birth is supported)
• emailInfo *
• phoneInfo *
• imInfo *
• recurringPayComponents *
• nonRecurringPayComponents *
• addressInfo (only address type home is supported)
• jobInfo
• compInfo
• employmentInfo
• emergencyContactInfo
• nationalId

Those marked with * can have multiple values sent to Employee Central by mapping a different keys for each entityType. Let’s look at Phone Number as an example:

Here we can see that both phone numbers (homePhone and cellPhone) are mapped to the same field in Employee Central (phone-number). However, these are differentiated by the Picklist external code of the value: H for Home phone and C for Cell phone.

Role Mapping

Because the candidates in Manage Pending Hires are not yet an employees, the permissions of the user cannot be applied to them. In order to apply permissions to enable the user to view and hire them, target roles are mapped with the <target-roles> element within the <role-mapping> element. Typically the user can only view candidates in Manage Pending Hires where at least one requisition operator is in the Target Population that is subject to the Permission Role containing the Manage Pending Hires access permission. However, mapping different roles (using the <roles> element) enables additional permissions to be available to the user that accesses Manage Pending Hires. There are five roles available:

• O: Recruiting Operator
• V: Requisition Approver
• R: Recruiter
• T: Sourcer
• G: Manager

While many customers do not change the recruiter role (R), some customers do re-use the Sourcer role (T) for another purposes (e.g. HR). Some caution should be applied when using the Requisition Approver role (V) as approvers can be added to a requisition on an ad-hoc basis and therefore it reduces how secure access to Manage Pending Hires can be.

In addition to mapping permissions, the manager role can be mapped using the <manager-roles> element within the <role-mapping> element. Again, the <role> element is used to map the role, although only one value can be mapped within the <manager-roles> element. Typically, this would be the manager role (G).

A sample code might look like:

Notes on the integration

There are a few notes to consider for the integration, including:

• The country used to determine country-specific fields for address, Job Information, and Compensation Information is derived from the address of the candidate
• If the country is passed over from the address it will be overwritten by the country of the Company if the country of the Company is different from the country passed from Recruiting
• The National ID country and type are not stored in Recruiting and therefore no values are transferred to Employee Central, although the values can be selected during hire
• A single frequency is used for all Pay Components sent to Employee Central and it must match the Code of the corresponding Frequency Foundation Object

For more details please see section 16.1.1.3.3 (Configuring Transformation Template) of the SuccessFactors Recruiting Management Implementation Guide.

How the integration works for the end user

In order for a candidate to be hired into Employee Central, a candidate must go through an approved Offer Approval process and then have their status set Ready to Hire in Recruiting.

Candidates are hired into Employee Central using the Manage Pending Hires transaction in OneAdmin, seen below:

The Pending Hires screen shows all of the candidates that are in Hirable status in Recruiting, as seen below:

To hire a candidate, the user simply selects the Hire button and this will launch the New Hire transaction in Employee Central. In this example, I’ll select the Hire button for Caroline Matthews. As we move through each stage of the New Hire process, we can see different data that has been pre-populated from Recruiting. For example, the employee’s address:

And Job Information:

And Compensation Information:

Once the candidate is hired in Employee Central then the User ID is sent to the Candidate Profile and the Candidate Profile background elements synchronize with the Employee Profile. We can now see the employee in Employee Central!

Summary

With a simple knowledge of XML – the staple of most SuccessFactors’ consultant’s weaponry – and a knowledge of Employee Central HRIS elements it is possible to quickly configure the transformation template that defines the field mapping used for the candidate to employee conversion between Recruiting to Employee Central. The robust integration is already in place, so simply configuring the transformation template should get the integration running quickly. This is another example of cross-suite integration in the SuccessFactors HCM suite at work.