Migrate from Longlist to BambooHR

Longlist candidate profiles map to BambooHR Applicant records within the built-in ATS. Since Longlist candidates are sourced independently of job openings and BambooHR applicants are attached to specific job positions, we resolve the position mapping during scoping: candidates associated with a specific opening receive a job ID reference; unsourced candidates are attached to a catch-all recruiting pipeline or held for manual position assignment post-migration. The applicant firstName, lastName, and workEmail fields map directly from Longlist's name and email properties.

Longlist email addresses map to BambooHR's workEmail field on the employee record. BambooHR enforces email uniqueness across the system and returns a 409 Conflict on duplicate creation. We run a dedupe scan against the destination org before migration and flag any existing employees with matching emails for conflict resolution.

Longlist phone numbers map to BambooHR workPhone or mobilePhone depending on whether the number is annotated as office or mobile in the source record. Longlist stores phone as a single unstructured field; we parse the number and assign it to the most appropriate BambooHR phone field based on format detection and any source annotation.

BambooHR has no native LinkedIn field. We create a custom text field (LinkedIn_Profile__c) via BambooHR's custom field builder before migration and write each Longlist candidate's LinkedIn profile URL into it. Field type is short answer and not marked required to accommodate candidates without LinkedIn presence.

Longlist tracks where candidate data originated (LinkedIn search, company website, boolean string, etc.) as a metadata property. This field has no BambooHR native equivalent. We create a custom text field Source_Attribution__c during setup and write the original source string from Longlist so hiring managers retain the sourcing context after migration.

Longlist sourcers attach freeform tags to candidates during research (skills, seniority, location qualifiers). BambooHR supports its own tag system on employee and applicant records. We evaluate during scoping whether to use BambooHR native tags (recommended for fewer than 50 distinct tag values) or a custom multi-select field (recommended if tag vocabulary is large or structured). The choice is documented in the scope document.

Longlist list or group assignments (e.g., 'Senior Engineers Q1', 'Passive Candidates - Refused Outreach') map to a custom lookup relationship in BambooHR if the group represents a persistent candidate pool, or to BambooHR native tags if the list is informal. We create a custom object or tag set during setup depending on the intended use of the group data.

Longlist candidates may carry a sourcer-applied status (Contacted, Not Interested, Qualified, etc.). BambooHR ATS pipeline stages are position-specific and not globally applicable. We map Longlist status values to the closest BambooHR pipeline stage (New Application, Phone Screen, Interview, Offer, Hired) during scoping. Any Longlist statuses without a BambooHR equivalent are written to a custom field Candidate_Source_Status__c.

Longlist enrichment data includes the candidate's current or most recent employer. This maps to BambooHR's currentEmployer field on the employee record or to a custom field on the applicant record. We preserve the original enriched employer name as-is; BambooHR does not resolve it to a formal company lookup entity.

Longlist's enriched job title for each candidate maps directly to BambooHR's jobTitle field on the employee record. BambooHR uses this field for org chart and reporting; we write the enriched title as the candidate's current or target title rather than inferring it from the job opening.

Longlist location data (city, state, country extracted during enrichment) maps to BambooHR's location field on the employee record. BambooHR uses location for reporting, headcount by office, and benefits eligibility groupings. We write the location string as stored in Longlist without normalization unless a specific normalization requirement is identified during scoping.