Demystifying Candidate Applications Integrations with SuccessFactors

[anoop20]

Introduction

SAP SuccessFactors Recruiting is one of such favourite topics which garner much attention from our implementation partners as well as large number of software partners too while extending the core ATS functionality to address variety of business needs from our customers.

With this blog, we would be primarily demystifying the relevant OData APIs which has been described in much more depth here with an IDP document and enabling our partners to overcome any candidate sourcing and job application related challenges during their development journey for solution extension capabilities.

Overview

With any typical solution extension, a candidate could be created into the system either via Candidate or CandidateLight endpoints which still triggers automated email notifications with a link to reset the password at the candidate email address. Candidate Light works in a much simpler manner and works with minimal set of four fields (country, firstName, lastName and primaryEmail) itself.

However, Candidate entity varies based upon settings in the tenant. Here, are the default required fields with a demo tenant but do also note the system mandatory field 'country' type Picklist as well to make integrations work.

Do note, these endpoints don't support deletion of any data and this should be managed directly by Data Retention and Purge Management.

And, for more details around the extended attributes like education, work experience, certifications etc. and various other business use cases like automating employee referrals, forwarding candidates including the handling of  bulk operations - do refer the comprehensive information provided with section 5.2 & 5.3 of the IDP - Guide to Leveraging Candidate and Job Application OData APIs  here.

Apart from candidate, creating job applications via APIs is one of the most complex operations considering the dependcies upon various other entities. So, it's pertinent to understand the logical relationships with all those entities and here is the simple representation of the same.

There are multiple hidden secrets around handling of data privacy consent statements, qualifying questions, rating scales and cascading questions, managing interviews etc. As an example, there are no APIs available to either query or update the DPCS and so it becomes the responsibility of the partner to manage DPCS for candidates. The JobApplication API does not validate if the candidate has accepted the DPCS or not. From an API perspective, the Candidate entity must be updated by setting the 'agreeToPrivacyStatement' property to either 'true' or 'false'. It's important to note such property values can't have other similarly sounding values like 'Yes' or 'No' and using any of such other combination values basically means candidate hasn't accepted the DPCS and candidate profile would be marked for anonymization. And, hence no longer can be actioned or available in search results.

So, if you are curious to know more about other business scenarios and have a holistic view around everything related to recruiting integrations, do have a look at the comprehensive content published at the community page for sample API requests corresponding to those varied use-cases.

In case you would like to know more about handling of Job Requisition integrations, please do refer the blog from my colleague @gerald_reinhard who introduced this topic along with related IDP document.

Special thanks to @aathanur  who had shared his wealth of experience along with other contributors who authored these documents last year while bringing them to the life for eco-system. 

References -

IDP - Guide to Leveraging Candidate and Job Application OData APIs

IDP - Guide to Leveraging Job Requisition OData APIs