Migrate from TalentLyft to Crelate

TalentLyft Candidates map directly to Crelate Contacts. The Candidate's email address becomes the Crelate Contact email field used as the dedupe key during import. First name, last name, phone, address, and source channel migrate directly. Any TalentLyft Candidate-level custom fields are mapped to Crelate Contact custom fields by retrieving field definitions via GET /v2/custom_fields before migration and cross-referencing against export values. Deduplication resolves by email match first; name plus phone as a secondary key for records without email.

TalentLyft Jobs map directly to Crelate Jobs. Job title, description, location, department, and status migrate as-is. The Job's assigned Pipeline ID is resolved to a Crelate pipeline configuration that is set up before Job import. Jobs must be imported before Applications so that the Job lookup on each Activity record is satisfied at the moment of insert.

TalentLyft Applications are junction records linking a Candidate to a Job with a Pipeline Stage assignment and optional Application-level custom fields. Crelate has no standalone Application object; instead, applications are modeled as Activity records with type = Application linked to the Contact (from the Candidate) and the Job. We map Application.pipeline_stage to Activity.status and carry any Application-level custom fields as structured JSON data inside the Activity record. The Activity is created after both the Contact and Job are staged.

TalentLyft Talent Pools are named curated collections of Candidates for future openings. Crelate has no named-pool object; the equivalent functionality is implemented using Tags on Contacts. We create a Tag category matching each TalentLyft Talent Pool name and apply the tag to every Contact that was a member of that pool. Tags are specified in the Crelate API as a JSON object keyed by category name. Customers using multiple Talent Pools per candidate get multiple tags applied.

TalentLyft Candidate-level custom fields vary per account and are entirely user-defined. We retrieve field definitions via GET /v2/custom_fields (Candidate endpoint) before migration to get field IDs, labels, and types. The corresponding Crelate Contact custom fields are created before migration begins. For fields with more than 10 values or complex types (multi-select, date), we run explicit field-by-field mapping sessions with the customer's admin. Values migrate as typed data matched to the Crelate field type.

Application-level custom fields in TalentLyft store per-application metadata such as interview scores, offer details, or compliance flags. These map to Crelate Activity custom fields. The same field-definition retrieval step applies: we call GET /v2/custom_fields (Application endpoint) to build the typed mapping table before migration. Application-level custom fields are carried inside the Activity JSON structure at import time.

Education records in TalentLyft are sub-records on an Application, containing degree, institution, field of study, and dates. The TalentLyft API exposes dedicated endpoints for create, update, and delete on education entries per Application. Migration requires a two-pass approach: Applications are first staged to resolve parent-record IDs, then sub-records are pulled using the Application ID in the path and attached to the corresponding Crelate Contact. Education maps to Crelate's Contact education sub-record structure.

Experience records (work history) in TalentLyft are sub-records on an Application with employer, title, dates, and description. Same two-pass approach applies: Applications are staged first, then experience sub-records are pulled and attached to the corresponding Crelate Contact as experience entries. The API supports CRUD on experience entries per Application. Employer and job title map directly; date ranges preserve as start and end date fields.

TalentLyft Pipelines define ordered stage sets assigned per Job. Crelate's pipeline stages are org-level picklist values shared across all Jobs rather than per-job. We configure the Crelate pipeline stage set during pre-migration setup, mapping each TalentLyft stage name and probability to a Crelate equivalent. Stage order is preserved in the picklist. This is an upfront configuration step; no data import depends on pipeline configuration beyond the Job-level reference.

Individual pipeline stages in TalentLyft (e.g., Applied, Phone Screen, Interview, Offer) map to Crelate picklist values within the configured pipeline stage set. Stage probability percentages migrate to the corresponding Crelate stage probability values. Stage names are mapped one-to-one where naming is consistent; synonym consolidation (e.g., 'Screening' and 'Phone Screen') is resolved during scoping with the customer's input.

TalentLyft Departments are organizational units used to categorize Jobs. The API exposes GET/POST for departments. We migrate department names and IDs and map them to Crelate Organization records, or link them to Jobs as a custom field if the customer's Crelate org does not use Organizations actively. The mapping decision is confirmed during scoping.

Locations in TalentLyft specify where a Job is based. The API exposes GET /v2/codes/locations. We migrate location records and link them to Crelate Jobs at the destination. Location names and addresses map directly to Crelate's location fields on Job records.

TalentLyft User accounts represent hiring team members (recruiters, hiring managers). The API lists users with roles and assignments. Migration resolves TalentLyft user emails to Crelate User records by email match. Users without a matching Crelate account go to a reconciliation queue for the customer's admin to provision before record import resumes, because OwnerId references are required on most Crelate objects.