As of today, there are many companies offering a cloud-based global Talent Acquisition Suite that allows teams to attract, select, and hire the best talent. It also makes it easy for companies to contract and manage all their recruiters and Hiring agencies from one platform giving them transparency as well as adequate control. This blog is basically to explain how the Integration between third party recruitment system and SuccessFactors (SF) Employee Central works.
As SuccessFactors gives a flexibility to implement any HCM module with no order, some of our customers first implement either Talent modules or Employee Central depending upon their business requirements and future roadmap. For those who opt to go with third party Recruitment providers with EC as system of record there is a need to build an Integration between Recruitment system and SF EC. The high-level steps are shown in below diagram. SAP Cloud Platform Integration (CPI) is just an example in this case for a cloud middleware (I will not deep dive into Recruitment process in this blog)
As shown in above diagram very first step is to sync the positions from the HRIS system (in this case SF EC) into the Recruitment system so that Requisition can be created against the EC positions.
If there's another third-party vendor for ex. ServiceNow which is reading positions from SF EC and synching with Recruitment system then we don't need to send position data from SF EC directly to Recruitment vendor.
Depending upon the recruitment system capabilities this can be done in various ways.
Once the candidate is selected and all Employee details have been captured in the Recruitment system then employee needs to be Hired in SF EC via Integration. There are various options to build such custom Integration. (SAP has given some out of box Integrations with third party Recruitment providers such as Kenexa which can be referred in SAP CPI.)
1.Sender (Recruitment) system triggers the Integration by calling the middleware and sending the candidate data: Sender can send data for one candidate at a time or multiple. Preferred is one candidate data per call to keep the Integration simple in terms of logic and reprocessing. Parallel triggers always possible. Middleware will have the logic to process the New Hire in SF EC. This is one of the best ways to build such Integrations. Real time trigger.
2.Middleware (ex. SAP CPI) reads the candidate data from Recruitment system and performs the New Hire/Rehire in SF EC: This will require more work for Integration Developer to study the Candidate objects and APIs of the Recruitment system before pulling the candidate data. This needs to be scheduled in SAP CPI so not real time.
4.Recruitment system generates a file with candidate data: SAP CPI consumes the file and processes the new hire in SF EC. This approach becomes little complex because we may get multiple candidates in same file. This makes the logic in middleware complex to separate data for each candidate and call the ODATA APIs in SF for each employee. This Integration needs to be scheduled in middleware and not real time.
You should also build a notification from middleware to Sender system about results of New Hire. If New Hire failed to process in SF EC, then it's a good practice that Sender system is informed so that necessary steps can be taken, and employee can be sent again. For option 1 you can send the success/error notification in same HTTPS request by which Sender has triggered the Integration and sent the data to middleware (i.e., you don't need to know endpoints for Sender system in this case).
Let's talk about the logic which needs to be built in the middleware to Hire the employee in SF EC. In EC we have employee data stored in various portlets. To perform the New Hire action on employee via middleware we need to call the ODATA APIs for those portlets in sequence (just like you do while importing the data for New Hires). Below APIs need to be called in sequence.
For all other portlets you can call the respective APIs (given below) in parallel.
For Rehire we don't need to call the User and PerPerson as employee already exists in SF EC but termniated. Call the EmpJob first and then EmpEmployment and then other APIs can be called.
Important: Many customers want to Integrate the third-party Recruitment system with 'Manage Pending Hire' functionality in SF EC. But it is actually not possible currently. Manage pending Hire works only between Recruitment and Employee Central module. Customers wish to have this functionality with third party Recruitment vendors also because they don't want to capture all information in the Recruitment system and expect to complete the Hiring and update remaining information directly in SF EC. This Integration is not possible because of similar reason why we can't do reporting on Manage Pending Hire. This data is not stored yet in the database. It is transient data between Recruiting and Employee Central, the information is not available in the domains.
FAQs:
1) Do we need to have a value for all required fields for each API call?
Yes
2) What if some required fields are populated via Business Rules in UI?
You have to write the logic in middleware to populate such fields (obviously if those required fields are not coming from sender)
3) Will the Position to JobInfo Sync be triggered via Position API call?
No
4) Will the Position to JobInfo Sync be triggered via Empemployment API call?
Yes (if you enable the PostoJob sync rule on position field in Job Info). When you call empemployment API by passing position iD, the rule will be triggered, and fields will be synced from Positon to JobInfo (those fields also which are not in your Integration mapping)
5) Will the HRIS sync be triggered after employee is created via ODATA APIs?
Yes
6) If we get an error while calling a ODATA API, how can we fix it?
Refer this link for more information.
7) The isFullTIme attribute in JobInfo is a required field and getting updated as 'No' but I haven't mapped this field in API. Why?
This attribute is defaulted to 'No' by the system (Refer this). You have to map this field with a value while calling the API.
8) The Employee id is generated when I hire an employee in UI. Is it the case via ODATA API also?
No
9) How can I get the next employee id in sequence while creating employee via ODATA API?
If employee number is generated from the Company settings (in SF EC) as shown below, then you can call the API 'generatenextPersonID' to read the next number in sequence
If there's a number range defined using Sequence MDF as shown below (for ex.) and a business rule reads this sequence and defaults the employee id in UI then it will be little tricky because we can't read the MDF 'Sequence' via middleware because the API visible property is not Visible in ODATA dictionary and SAP doesn't allow you to change that property. You can either read all the employee ids and do a + 1 but there also you may face challenges if some existing employee ids in SF EC are alphanumeric (then you have to ignore such ids).
10) Can I call the 'Add new employee' wizard from middleware like we Hire employee in UI in SF EC?
No (I wish we could)
As SuccessFactors gives a flexibility to implement any HCM module with no order, some of our customers first implement either Talent modules or Employee Central depending upon their business requirements and future roadmap. For those who opt to go with third party Recruitment providers with EC as system of record there is a need to build an Integration between Recruitment system and SF EC. The high-level steps are shown in below diagram. SAP Cloud Platform Integration (CPI) is just an example in this case for a cloud middleware (I will not deep dive into Recruitment process in this blog)
As shown in above diagram very first step is to sync the positions from the HRIS system (in this case SF EC) into the Recruitment system so that Requisition can be created against the EC positions.
If there's another third-party vendor for ex. ServiceNow which is reading positions from SF EC and synching with Recruitment system then we don't need to send position data from SF EC directly to Recruitment vendor.
Depending upon the recruitment system capabilities this can be done in various ways.
- SAP CPI extracts all the approved positions (this varies upon client specific requirement whether 'To be hired' flag can be used to filter positions or any other field from position MDF) and creates a file on a SFTP server. Recruitment system picks the file and syncs the position data.
- If Recruitment system supports API then SAP CPI can directly sync the positions from SF EC. This will require more work for Integration developer to understand the Recruitment system APIs and perform mapping of various fields from EC position MDF to Position object in receiver system.
Once the candidate is selected and all Employee details have been captured in the Recruitment system then employee needs to be Hired in SF EC via Integration. There are various options to build such custom Integration. (SAP has given some out of box Integrations with third party Recruitment providers such as Kenexa which can be referred in SAP CPI.)
1.Sender (Recruitment) system triggers the Integration by calling the middleware and sending the candidate data: Sender can send data for one candidate at a time or multiple. Preferred is one candidate data per call to keep the Integration simple in terms of logic and reprocessing. Parallel triggers always possible. Middleware will have the logic to process the New Hire in SF EC. This is one of the best ways to build such Integrations. Real time trigger.
2.Middleware (ex. SAP CPI) reads the candidate data from Recruitment system and performs the New Hire/Rehire in SF EC: This will require more work for Integration Developer to study the Candidate objects and APIs of the Recruitment system before pulling the candidate data. This needs to be scheduled in SAP CPI so not real time.
3.Sender system sends a notification to Middleware using webhooks: Webhooks are basically user defined HTTP calls (or small code snippets linked to a web application) which are triggered by specific events. So, when candidate is onboarded a notification with candidate id can be sent to middleware and then middleware extracts all the candidate data using the candidate id and performs New Hire in SF EC. This will also require work for Integration Developer to study the sender system APIs before extracting the data. Real time trigger.
4.Recruitment system generates a file with candidate data: SAP CPI consumes the file and processes the new hire in SF EC. This approach becomes little complex because we may get multiple candidates in same file. This makes the logic in middleware complex to separate data for each candidate and call the ODATA APIs in SF for each employee. This Integration needs to be scheduled in middleware and not real time.
You should also build a notification from middleware to Sender system about results of New Hire. If New Hire failed to process in SF EC, then it's a good practice that Sender system is informed so that necessary steps can be taken, and employee can be sent again. For option 1 you can send the success/error notification in same HTTPS request by which Sender has triggered the Integration and sent the data to middleware (i.e., you don't need to know endpoints for Sender system in this case).
Let's talk about the logic which needs to be built in the middleware to Hire the employee in SF EC. In EC we have employee data stored in various portlets. To perform the New Hire action on employee via middleware we need to call the ODATA APIs for those portlets in sequence (just like you do while importing the data for New Hires). Below APIs need to be called in sequence.
- User
- PerPerson
- EmpEmployment
- EmpJob
For all other portlets you can call the respective APIs (given below) in parallel.
- PerEmail
- PerPhone
- PerPersonal
- PerNationalId
- EmpCompensation
- PerAddressDEFLT
- EmpJobRelationships
For Rehire we don't need to call the User and PerPerson as employee already exists in SF EC but termniated. Call the EmpJob first and then EmpEmployment and then other APIs can be called.
Important: Many customers want to Integrate the third-party Recruitment system with 'Manage Pending Hire' functionality in SF EC. But it is actually not possible currently. Manage pending Hire works only between Recruitment and Employee Central module. Customers wish to have this functionality with third party Recruitment vendors also because they don't want to capture all information in the Recruitment system and expect to complete the Hiring and update remaining information directly in SF EC. This Integration is not possible because of similar reason why we can't do reporting on Manage Pending Hire. This data is not stored yet in the database. It is transient data between Recruiting and Employee Central, the information is not available in the domains.
FAQs:
1) Do we need to have a value for all required fields for each API call?
Yes
2) What if some required fields are populated via Business Rules in UI?
You have to write the logic in middleware to populate such fields (obviously if those required fields are not coming from sender)
3) Will the Position to JobInfo Sync be triggered via Position API call?
No
4) Will the Position to JobInfo Sync be triggered via Empemployment API call?
Yes (if you enable the PostoJob sync rule on position field in Job Info). When you call empemployment API by passing position iD, the rule will be triggered, and fields will be synced from Positon to JobInfo (those fields also which are not in your Integration mapping)
5) Will the HRIS sync be triggered after employee is created via ODATA APIs?
Yes
6) If we get an error while calling a ODATA API, how can we fix it?
Refer this link for more information.
7) The isFullTIme attribute in JobInfo is a required field and getting updated as 'No' but I haven't mapped this field in API. Why?
This attribute is defaulted to 'No' by the system (Refer this). You have to map this field with a value while calling the API.
8) The Employee id is generated when I hire an employee in UI. Is it the case via ODATA API also?
No
9) How can I get the next employee id in sequence while creating employee via ODATA API?
If employee number is generated from the Company settings (in SF EC) as shown below, then you can call the API 'generatenextPersonID' to read the next number in sequence
If there's a number range defined using Sequence MDF as shown below (for ex.) and a business rule reads this sequence and defaults the employee id in UI then it will be little tricky because we can't read the MDF 'Sequence' via middleware because the API visible property is not Visible in ODATA dictionary and SAP doesn't allow you to change that property. You can either read all the employee ids and do a + 1 but there also you may face challenges if some existing employee ids in SF EC are alphanumeric (then you have to ignore such ids).
10) Can I call the 'Add new employee' wizard from middleware like we Hire employee in UI in SF EC?
No (I wish we could)
- SAP Managed Tags:
