Building an integration from a third party ATS to SuccessFactors Onboarding

[NathanWilkinson]

When you integrate SuccessFactors Onboarding with an external ATS there are a few areas that will require some consideration.  In this article we are only looking at the data from the ATS to SuccessFactors Onboarding and not SuccessFactors Onboarding to the ATS. We will look at some of these key considerations and learnings to allow customers who use a third party ATS to quickly build an integration to SuccessFactors Onboarding using CPI.

Initiating onboarding

When you initiate onboarding via an API, you are effectively ‘importing’ and ‘saving’ a record in SuccessFactors.  Some of the data attributes required to save a record may not be available in the ATS, for example, Date of Birth (DOB).  In EMEA, DOB is not collected during the recruitment process, therefore if DOB is required in Employee Central you will need to do the following.

Make DOB not mandatory in the main data model.

Make DOB mandatory in both the employee and onboarding person types.

However, when you import data into Employee Central the system looks at the mandatory fields in the data model and not the person types.  Therefore, to ensure employees are not imported into Employee Central without a DOB you need to build a rule to ensure DOB is imported.

You will need to adjust the rule contexts as follows.

You will need to repeat the same procedure for employment and job information for all required fields that are not on the position and not collected in the ATS.  However, in compensation you do not have person types, in this case we make the fields not mandatory in the data model and build a rule to trigger both ‘oninit’ and ‘onview’ to make the fields required.  You will need to build a rule to ensure data is imported correctly. 

We would normally advise that rules are not enabled for imports as it can make the imports run slowly.  Therefore depending on the size of the imports it may be easier to turn off the rules and ensure the import templates are populated correctly with the mandatory data.

You do not need to worry about portlets like ‘address’ or ‘national id’ as these fields only become required if you are adding data for that portlet.

We preferred this approach to the alternative of setting ‘dummy values’ in the integration and then using business rules to ‘strip’ out the dummy data in the UI.

Validation of Data

If you are passing data like ‘post code/zip code’ and you have ‘address validations’ enabled in Employee Central, you need to be aware that the integration will fail if the data is stored differently in the ATS.  For example, UK postal code TA19 7KL, if this is stored in the ATS as TA197KL when passing this value the interface will fail as it will not be able to save the onboarding record because it does not meet the correct format ‘TA19 7KL’. 

Address can be problematic as ATS can store ‘addresses’ in one field and not spilt out the data into multiple fields like it is in Employee Central, as a result it can be quite tricky to map the addresses and it may be easier to ask the candidate to re-enter their address in onboarding when you know all address validation will be triggered.

Rules

When the API creates the record, the assigned rules should trigger.  It is important during testing to ensure that all rules are triggering. In the integration we set the value of the pay component to ‘Base Salary’ and only send across the ‘amount’.  During testing we discovered that we needed to adjust the ‘oninit’ rule to prevent the rule from stripping out the values in the integration.

Here is the original rule and behavior.

We needed to adjust the rule to help us create a ‘read only’ custom field in employment info with three values, EC, ATS and ONB.  By adjusting the rule as follows we were able to get the correct behavior.

The custom field was set as follows, ATS can only be set by the integration, ONB is set by the following rule, which is triggered ‘onchange’ of department.

We also have this rule ‘onchange’ of department to set the value ‘EC’. 

This field has become very useful in allowing other rules to behave different depending on if the data comes from the ATS, or manually started from onboarding or hired directly into Employee Central.

This field gives you flexibility to not rely on using ‘If process = onboarding’ as it allows you to trigger rules differently during New Hire Data Review if you have data in the fields from the ATS.

Position management

If you are using position management then the integration and data flow is simpler as you can pass back the position code, and this will trigger the data propagation from the position.  If you are not using position management then passing organizational data will become harder as many ATSs do not structure organization and job data like it is in Employee Central.

Phone numbers

In the ATSs many phone numbers may be parsed from a CV and as a result may contain non-numeric characters like parentheses.  If you pass non-numeric characters, they will be accepted in Employee Central, but they will cause a problem for USA I9 forms.  Whilst you can try and build logic in the interface to strip out non-numeric characters, we implemented the following rule to trigger in onboarding.  We only wanted this to trigger in Onboarding and for candidates in the USA.

We also adjusted the context as follows.

Hiring Manager

Not all ATSs will store all the active managers from Employee Central, keeping an active set of users in the ATS would require an integration from Employee Central to the ATS.  This can be particularly complicated to build.  What we were able to do in the integration from the ATS is send across the manager email address and use this to assign the manager in Onboarding.  This is a free text field and whilst it does rely on the recruiter adding in the correct address it has allowed the integration to be built quicker.

Use of New Hire Data Review

If you pass data from the ATS then it maybe worth using New Hire Data review step to review all the data that has been sent to Onboarding.  Onboarding has a number of review steps that can be used, and a previous article [https://community.sap.com/t5/technology-blogs-by-sap/understanding-the-data-review-steps-in-onboardi...] discusses these in more detail.

Conclusion

Building an integration from a third party ATS to Onboarding is relatively straight forward to achieve with CPI.  The main area of consideration will be how ‘organizational data’ is stored in the ATS and how the Employee Central rules trigger if the process starts from the ATS compared to manually in Onboarding or directly in Employee Central.