About:
Often there is a requirement to fetch the new hire data from SuccessFactors (SF) Recruiting before onboarding is initiated for the candidate for various reasons.
The reasons could be that we need to create the employment contract in ServiceNow, and we need that to be signed by the candidate before they can be entered into SF Employee Central (EC).
Although, the SuccessFactors spoke can connect with SF, it can only fetch data from EC and does not provide any OOTB actions to fetch data the RCM module.
In this article we will look at the steps on how you can create an integration to fetch candidate data from SF RCM.
Mapping:
RCM has 3 main templates; it is paramount to understand which fields needs to be fetched and from where.
You should ideally have a workshop with the SF RCM owner and discuss the fields, their location and the data type and create a mapping table.
The 3 templates in RCM are:
- Job Requisition,
- Applicant details, and
- Offer Letter
Trigger and Identification:
You first want to find out how to identify the candidates that needs to be fetched from SF RCM to SN.
This could be by identifying the candidates that are in a certain state in the candidate pipeline of the Job Requisition. You could select state such as "Ready for hire" or "Offer accepted".
The flow that you would make to fetch the data from SF to SN can be scheduled to run daily or even hourly.
Create a system property which stores when the job was last run. This will help you fetch only the data that was modified after your last run for the candidates who are in the right state in SF RCM.
Flow:
If you have implemented the SuccessFactors Spoke, you can use the same scope and connection/credentials to connect to SF RCM.
You can mimic the SF EC flow to fetch all data or only last modified from data.
Further mimicking the SF EC flow you can have the flow call a subflow where you’d call the action and create/update the candidate record in SN. You’d use the for each Item in <Action>
We will use our flow to create both user profile and HR profile.
You do not necessarily need a staging table; you can have the flow create/update the user profile and HR profile records.
Action:
Mimic one of the OOTB actions like Retrieve Departments to have the various necessary steps:
Ensure that you have added the fields that you need in the outputs of the action so that you can populate it in the parser step.
Step 1: Create Resource path:
This is where your mapping table would come in handy. You need to ensure that your resource path has the fields that you are trying to fetch.
For example, this step can look like below. Notice the var expand and select in the code below.
function execute(inputs, outputs) {
var util = new SuccessFactorsUtil();
var retrieveAll = inputs.retrieve_all;
var date = util.convertDateToUTC(inputs.retrieve_modified_from);
var format = 'JSON';
var expand = [
'jobRequisition',
'candidate',
// 'candidate/title',
'jobOffer',
'jobRequisition/location_obj',
'jobRequisition/legalEntity_obj',
'jobRequisition/department_obj',
'jobRequisition/hiringManager',
'jobAppStatus',
].join(',');
var select = [
'firstName',
'lastName',
'applicationId',
'title',
'startDate',
'dateOfBirth',
'lastModifiedDateTime',
'candidate/candidateId',
'candidate/country',
'candidate/primaryEmail',
'jobRequisition/jobStartDate',
'jobRequisition/positionNumber',
'jobRequisition/positionName',
'jobRequisition/location_obj/name',
'jobRequisition/country',
'jobRequisition/legalEntity_obj/name',
'jobRequisition/hiringManager/firstName',
'jobRequisition/hiringManager/lastName',
'jobOffer/customDate1',
'jobOffer/custHoursPerWeek',
'jobRequisition/department_obj/name',
'jobAppStatus/appStatusName',
].join(',');
var resourcePath = 'JobApplication?$format=' + format + '&$expand=' + expand + '&$select=' + select + '&$filter=jobAppStatus/appStatusName eq \'Offer Accepted\'';
if (!retrieveAll || retrieveAll == 'false') {
try {
if (typeof(date) == 'string' && date.trim() != '') {
var second_filter = " and lastModifiedDateTime ge datetimeoffset'" + date + "'";
resourcePath = resourcePath + second_filter;
} else {
throw new Error("When 'Retrieve All Todos' is false, 'Retrieve Todos Modified From' is mandatory");
}
} catch (e) {
throw new Error(e);
}
}
outputs.resource_path = resourcePath;
})(inputs, outputs);
- Pagination step:
You can leverage the same as the other OOTB action.
- REST step:
Same as the other OOTB actions, your resource path creates in step 1 is what drives what you fetch from SF.
- Splitter step:
Same as OOTB action.
- Script parser step:
Here you’ll populate the output of the action. You will need to extract based on the item in the parser. See example below:
(function parse(inputs, outputs) {
var item = JSON.parse(inputs.sourceItem)
//jobApplication fields
if (item.firstName) {
outputs.targetObject.first_name = item.firstName
}
if (item.lastName) {
outputs.targetObject.last_name = item.lastName
}
if(item.applicationId){
outputs.targetObject.candidate_id = item.applicationId;
}
//jobApplication/candidate fields
if (item.candidate) {
outputs.targetObject.personal_email = item.candidate.primaryEmail || "";
}
//jobApplication/jobRequisition fields
if (item.jobRequisition) {
outputs.targetObject.position = item.jobRequisition.positionName || "";
outputs.targetObject.position_number = item.jobRequisition.positionNumber || "";
outputs.targetObject.country = item.jobRequisition.country || "";
Recommendations/Tips:
In general, the data from SF should be fetched from SF EC. You should only fetch the data from a different module if there is a business use case to support it.
You should fetch a primary ID from RCM into SN such as applicant ID. This ID should also be transferred to SF EC so that it can later be used to match the users in the systems.
This is important as RCM does not have the person ID, as this is generated in EC.
