iCIMS Applicant Feed Implementation Guide

Purpose
The scope of this integration guide covers a one-way data synchronization from the iCIMS ATS through Radancy’s Applicant Importer and consuming services: CRM, Employee Referrals, Insights & Analytics. The terms Applicant or Candidate can be used synonymously across ATS and Radancy systems, unless specifically stated.
 

Integration Security
Our standard integration workflow requires basic authentication. When we are standing up an integration, we
prefer to begin using a staging application so that the data available is test data rather than live candidate data. Therefore, we normally expect two sets of credentials over the full integration lifecycle. To begin with the credentials will be for the staging application, once the integration is vetted, we will need a production application user provisioned to enable the live integration.


The data in the staging application should mirror the data collected in the production instance so that we can ensure the mappings are working as desired. We require applicant data, and job data in the sandbox for proper UAT.

IP Whitelisting

The following Radancy Server IP addresses are required to be whitelisted within your iCIMS instance
 

[North America Hosting]

  • 3.214.163.179
  • 3.217.163.207
  • 3.217.100.148

[EU Hosting]

  • 3.124.173.206
  • 3.121.60.93
  •  3.124.111.6

[Developer Workstation]

  • TBD based on resource assignment

 

API Calls

Our integration (Scheduled Import) is based on a predetermined interval (ex. Once every 24hrs). Using the current date time as end time, and then based on frequency, determine start time. For example, if frequency is hourly, start time will be current date time - 1 hour.

1. A call is made to Get updated job applications.

Endpoint: "/customers/{settings.CustomerId}/search/applicantworkflows"

Invoke with HttpPost with start/end date range filter.

Related ICIMS doc link for http call: https://developer.icims.com/REST-API/Object-Types-Commands/Search-API

This API will return a list of updated job applications within start/end time range. We're only interested in collecting the job application ids to pass in our next call.

2. Get job application details

With the application ids collected from the step above, we will call the endpoint below to get details about any given job application.

Endpoint:
"/customers/{customerId}/applicantworkflows/{workflowId}?staleness=0&fields=updateddate,baseprofile,associatedprofile,status"

Related ICIMS doc link for response model: https://developer.icims.com/Data-Models/Recruiting-Workflow

This API will return candidate id (profile id as it’s called in the API) as well as job id for use in the next two calls.

3. Next we Get candidate details

With the candidate ids from step above, we will call the endpoint below to get details about candidates.

Endpoint:
"/customers/{settings.CustomerId}/people/{candidateId}?fields=email,firstname,lastname,education,workexperience,phones,addresses"

Related ICIMS doc link for response model: https://developer.icims.com/Data-Models/Person-Profile/Person

4. Finally we Get job details

With the job ids collected above, we will call the endpoint below to get details about jobs.

Endpoint: "/customers/{settings.CustomerId}/jobs/{jobid}?fields=joblocation,positioncategory,jobtitle"

Related ICIMS doc link for response model: https://developer.icims.com/Data-Models/Job-Profile/Standard-Fields

 

Radancy Applicant Model

The data pulled from the APIs will be mapped against Radancy’s standard applicant model for use within your
Radancy TAC platform. A sample of our model is displayed below with added context for the value or purpose of
the individual attributes.

Requested Data Purpose
Applicant Id ATS unique identifier
Start Date Nullable DateTime. Applicant’s start date (Hired state)
Address (Address, city, state, country, ZIP) Physical location
Applications Can be one of multiple for an individual
Application Id Individual application identifier
Req Id Associated job id (per application) – this will provide a link from the applicant profile to the job in CRM for all active jobs
Title Job title – to display in CRM
Status Current Status – needed for each application in a profile
Updated Indicator of the date/time for the change in status allows for assessing priority
Job Information Job req info
Business Unit  
Department  
Function  
Position Level  
Job Category  
Job City  
Job State  
Job Postal Code  
Job Region  
Job Country  
Custom Fields Optional, ad hoc usage – lets discuss if you have needs
Educations Applicant education experiences, this information will populate in the prospect profile in CRM
School Name  
Major  
Degree Obtained  
Date Range Years attended
Email Address Necessary unique identifier in our applicant system
First Name  
Last Name  
Phone Numbers Phone numbers related to candidate profile, can have multiple fields for difference phone number types
Professional Summary  
Certification Any known certifications
Work Experiences Experience history of prospect will add content to profile in CRM
Company Name  
Title Position/job title
Work Description Many more skills can be derived if we get better descriptions from the applicant's profile (if available)
Date Range Start and end dates for experience
Social Network Links LinkedIn, Facebook, GitHub, etc
Military service Info Resume Data (Raw resume) Branch of service, rank, dates. We can consume, display and parse this for data enrichment

*Note – We understand the data available in your ATS will not necessarily encompass all these attributes.
However, Radancy will work with you to identify the final mapping of your collected data against our standard
model. We can also utilize resume documents/attachments to enrich applicant profiles within the CRM
application. The ability to parse resumes will be dependent on the integration type available (API). Only the
most recent application’s associated resume document for the applicant will be saved/stored for
recruiting/sourcing use cases.

 

Was this article helpful?
0 out of 0 found this helpful