Update Levels
Full Update
A full update requires sending the complete record of the candidate resume and structured data trace message format (TMF
) 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
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
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
Application
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 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 query
The lightweight update is done through the Search! Update 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.)