Resume Parsing with Textkernel: Parsing Architecture and Field Mapping

Overview

This article describes how data is mapped from resumes parsed by Textkernel to Contact records in Bullhorn for Salesforce.

An Org must be upgraded to Bullhorn for Salesforce package v.3.389 or newer to take advantage of this architecture.

The following Custom Setting must be enabled for the field-mapping process described in this article to work: Setup > Custom Settings > Talent Rover Properties > Manage Records > Enable New Architecture.

How it Works

The Textkernel parser is designed to validate mobile/phone numbers, so the parser looks for international prefix codes/calling codes. If those are not found, the parser will look at what country is specified in the address to work out the relevant prefix/international code. The parser can also look for other identifiers (not specified by Textkernel) to determine the category of the number (mobile/home phone) if the address is invalid.

If you notice what appears to be incorrectly parsed phone numbers added to a contact record as a result of resume parsing, please contact Textkernel Support to explain how the phone numbers were extracted.

The Generic Parser

Bullhorn for Salesforce has designed a generic parser that can handle field mapping from resume to Contact record from any Search and Match provider. The Search and Match provider is identified by the Search and Match Configuration (TR1__Search_Match_Configuration__mdt) Custom Metadata Type.

When the Provider Type is Textkernel, the relevant TextkernelParser and TextkernelProvider API API, or Application Programming Interface, is used by customers to create custom career portals or to take advantage of Data Mirror/DataMart. Bullhorn prefers to use REST API. classes will be called.

The whole idea of the generic parser is to avoid the use of multiple IF clauses that have hard-coded references to the XML Used to create custom markup languages in order to display information on the Internet. We use XML when sending jobs to Indeed for syndication. Nodes names and Fields on the Contact object.

The generic parser will iterate the list of records in the Candidate A person looking for a job. A candidate can also be referred to as a Job Seeker, Applicant, or Provider. Mapping (TR1__Candidate_Mapping__mdt) Custom Metadata Type. Each record represents a field value that needs to be stored in Bullhorn for Salesforce and will be fetched using an XPath expression. The generic parser will employ the SObject methods – put( fieldname, object ) to place the value into the respective field on the Contact record without hard-coding references.

The generic parser currently supports field mapping to the following Bullhorn for Salesforce objects: Contact, Employment History, and Education History. The Object field on the Candidate Mapping Custom Metadata Type record captures the name of the Object for any field included in the mapping.

Candidate Mapping Custom Metadata Type

To access this setting go to Setup > Custom Metadata Types > Candidate Mapping (TR1__Candidate_Mapping__mdt). This Custom Metadata Type will have no records after upgrading to v. 3.389 or higher for the first time. This article provides the recommended mapping configuration and will explain how to create the records and what fields should be mapped, but the specific field mapping for each Org will be decided by the System Administrator.

Candidate Mapping Custom Metadata Type Fields

For each field to be mapped, create a separate Custom Metatdata Type record against the Candidate Mapping Custom Metadata Type. The screenshot above shows what a filled in record looks like. Below is a list of the available fields and their function:

Field Name	Function
Label	Master Label (label can be changed)
Candidate Mapping Name	Developer Name (label can be changed)
Action When used in ATS or Search and Match UI, one of multiple actions available after user has selected a sub-set of Candidates	Picklist Values: Merge, Do nothing, Override
Object	API name of Bullhorn for Salesforce Object: Contact, Education History, Employment History
Field API Name	API Name of the Bullhorn for Salesforce object field
Default Value	Value to be added automatically if a field Value is returned as NULL from parser
XPath	Path to the specific node in the XML file
XML Node	Node in the XML corresponding to the Contact field

Field Details

Action: This field controls the Record Update behavior. During parsing, a check happens to see if the destination field in Bullhorn for Salesforce is already populated. If it is populated, these are the options:

• Merge: Add the new value to the existing one.
• Do nothing: Do not update the field.
• Override: Replace existing value with new value.
• Conditional Override: Replace existing value with new value only if the new value is not blank.

Default Value: The value to be added if a field is returned as NULL from Textkernel (for example, you can decide to have "Unknown" as the default value in the case where a name is not parsed from a resume).

The Action and Default Value fields are not in use when the field mapping is to the Employment History or Education History Objects.

Field Mapping Examples

Below are two examples of how a Candidate Mapping Custom Metadata Type record is mapped from the XML record, so it is clear how data is used in this process.

Example 1

<Candidate>
    <Personal>
        <FirstName>John<FirstName>
        <LastName>Smith<LastName>
        <Initials>JC</Initials>
        <Gender>Male</Gender>
        <Email>john.smith@yahoo.com<Email>
        <MobilePhones>
            <MobilePhone>+12188675309</MobilePhone>
        <MobilePhones>
    <Personal>
<Candidate>    
        

Using the above image, create a new record in Candidate Mapping Custom Metadata Type for Mobile:

XPath: The Xpath field needs the complete Path of the Node from to the desired value. When the code will be executed for the following :
XPath / XML Node: Candidate/Personal/MobilePhones/ MobilePhone
It will get this value “+347875723446”.

Example 2

This second example to further clarifies the importance of the Xpath field. The data we want to map is the location of the Candidate’s employers.

<EmploymentHistory>
    <EmploymentItem>
        <JobTitle>Junior Front-end Web Developer</JobTitle>
        <EmployerName></EmployerName>
        <EmployerLocation></EmployerLocation>
        <Address>
            <EmployerCity>Madrid</EmployerCity>
            <EmployerRegion>ES Madrid</EmployerRegion>
            <EmployerCountry>Spain</EmployerCountry>
        <Address>
        <YearsExperience>8</YearsExperience>
        <Dates>
            <StartDate>2011-10-01</StartDate>
            <EndDate>
                <YearMonth>2019-10<YearMonth
            </EndDate>
        <Dates>
    </EmploymentItem>
<EmploymentHistory>    
            

To get the value of Region from the XML node, the following two fields are important:

XML Node: EmployerRegion

XPath: Address

The XPath field considers the complete path of the Node from that holds the desired value. When the code will be executed for the following:
EmploymentHistory / EmploymentItem / XPath / XML Node:
EmploymentHistory / EmploymentItem / Address / EmployerRegion

This value “ES Madrid” is returned. EmploymentHistory and EmploymentItem will be added in the code.

Candidate Mapping

These tables provide the recommended configuration for the Candidate Mapping Custom Metadata Type.

Contact Fields

Select “Contact” in the Object Field.

Below are 2 configurable Contact fields. If these values are required for your Organization, add the following field records in the Custom Metadata Type.

Education History Fields

Select “TR1__EducationHistory__c” in the Object Field.

Employment History Fields

Select “TR1__EmploymentHistory__c” in the Object Field.