Update Levels

Full Update

A full update requires sending the complete record of the candidate A person looking for a job. A candidate can also be referred to as a Job Seeker, Applicant, or Provider. resume and structured data trace message format (TMF A technical term, not specific to BH4SF. It's a file format used in parsing.) to the parsing endpoint to complete a full reparse. This type of update requires the most time and infrastructure resources because it is parsing the candidate’s resume again, even if the content has not changed. These steps occur during a full update:

• Parsing the resume document
• Merging extracted data with TMF
• Normalizing the fields (such as translating a job A job (vacancy, position, role) is an opening for which a customer's client needs a placement. title to a job code)
• Computing extra fields (years of experience given the list of employment items)
• Indexing in Search

Partial Update

A partial update sends only the structured data that has changed to the parsing endpoint. Because the data from the resume does not need to be fully extracted again, this is a lighter update than a full update. A partial update does still normalize and recalculate the data indexed in Search. These steps occur during a partial update:

• Retrieving previously parsed documents
• Merging extracted data with TMF
• Normalizing the fields (such as translating a job title to a job code)
• Computing extra fields (years of experience given the list of employment items)
• Indexing in Search

The Textkernel Search and Match Integration uses a partial update in the following situations:

• Existing Contact record update
• New Contact Document record creation (manually, without parsing)
• Call List Member creation or update
• Job Board A website where open jobs are advertised Application First stage of Job placement flow (Application> Submittal>Interview>Offer> Placement) record creation or update
• Education History record creation or update
• Employment History record creation or update

Lightweight Update

The lightweight update allows updating of fields in the index A collection of files that can be searched by client data entity types. When records can be found in training login, but not the live system, it may require a bootstrap of the index. which changes the data directly in Search, skipping all normalization and recomputation steps. Lightweight update is suitable for fields that are logic-less and don’t have influence on other fields, such as availability date or expected salary.

Field Limitations

Several types of fields are not suitable for the lightweight update because they require normalization or recomputation to be useful in semantic search. These types of fields should not be included:

• Fields requiring normalization, such as Job Title, which needs to be normalized into job codes
• Fields requiring computation, such as Years of Experience, that are calculated based on the listed employment history
• Fields that are infrequently updated. If the field is populated when the candidate record is first created and then rarely, if ever, changed would not benefit from being included.
• Fields that might be used to generate a Match! query

The lightweight update is done through the Search! Update 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. requiring only:

• A Contact ID
• Field Name
• New Field Value (The field value will be written as-is to the index. If it is a multi-value field, all values must be written.)