Migrate from Longlist to Bullhorn ATS & CRM

Longlist Candidate records map to Bullhorn Candidate entities. The Longlist display name maps to firstName and lastName; email maps to email; phone maps to phone; LinkedIn profile URL maps to LinkedIn (custom Char field or Bullhorn standard field depending on Bullhorn edition). We use the Candidate entity as the primary record and resolve any required fields (name, email) before insert. Bullhorn requires at minimum a firstName or lastName; records with no name are flagged during scoping for admin review.

Longlist contact fields (email, phone, LinkedIn) map directly to Bullhorn Candidate standard fields: email to Candidate.email, phone to Candidate.phone, LinkedIn URL to Candidate.linkedIn. These are Bullhorn native fields and do not require custom object setup. Longlist also surfaces secondary email addresses and alternative phone numbers; these land in Bullhorn Candidate custom character fields (customText1–customText10) provisioned by Bullhorn Support.

Longlist records carry a source attribution indicating where the candidate data was found (LinkedIn Recruiter, company website, job board, etc.). This maps to Candidate.source (Bullhorn standard). Any enriched data provenance (the specific enrichment provider or scrape source) lands in a Bullhorn custom character field (customChar1) that Bullhorn Support provisions on the Candidate entity. Source values that do not match Bullhorn picklist values are pre-loaded into the picklist during migration configuration.

Longlist sourcers apply freeform tags to candidate records during research. Bullhorn does not have a native tag system equivalent; we map these to a Bullhorn custom multi-select picklist field (customMultiSelect1) provisioned on Candidate by Bullhorn Support. Pre-migration, we extract all distinct tag values from Longlist, create the corresponding picklist entries in Bullhorn, and bulk-apply the multi-select values during candidate import. Tags used for segmentation (sourcer name, pipeline stage) are treated as separate custom fields rather than merged into one multi-select.

Longlist lists (e.g., 'Tech Leaders Q1', 'Passive Candidates', 'VIP Sourced') map to Bullhorn Candidate Lists. Each Longlist list becomes a Bullhorn Candidate List. Candidate membership migrates as a Candidate List membership record linking the Candidate to the List. If Longlist lists overlap (a candidate in multiple lists), Bullhorn Candidate List membership supports many-to-many relationships natively, so no candidate duplication occurs.

Longlist does not have a native Company entity; company context is embedded in the candidate record (the employer or target company the sourcer was researching). We extract employer or target company names from Longlist candidate records and create Bullhorn ClientCorporation entities during migration. Each Candidate then links to its ClientCorporation via the candidateToClientCorporation relationship. If the employer name is absent or ambiguous, the Candidate is created without a corporation link and flagged for the admin to resolve post-migration.

Longlist surfaces enrichment attributes that extend beyond standard contact fields—confidence scores, data freshness timestamps, social handle URLs, technology stack signals, or sourcing-tool metadata. Bullhorn supports up to 10 custom objects per Candidate entity (customObject1s through customObject10s). Each custom object must be provisioned by Bullhorn Support before migration. We coordinate with the customer's Bullhorn Support contact to pre-create the custom objects, then populate them via the Bullhorn REST API during migration. Custom object fields are typed (Char, Int, Float, Date, Bool, Lookup) and we map Longlist attribute types to Bullhorn field types during schema design.

Longlist sourcers frequently add internal research notes to candidate records during the enrichment phase. Bullhorn does not have a native 'research note' field on Candidate; we migrate these as Bullhorn Note records attached to the Candidate via ContentDocumentLink. The Note body preserves the full research comment. If Bullhorn's document management (ContentDocument/ContentVersion) is not enabled on the destination org, we fall back to Bullhorn Note records without ContentDocumentLink attachment.

Longlist does not store job orders, requisitions, or placement records. Bullhorn JobOrder and Placement entities cannot be populated from Longlist data. During scoping, we confirm whether the customer has any job or placement data held outside Longlist (in spreadsheets, email, or another system) that should be migrated in parallel. If no external data exists, JobOrder and Placement entities are created empty in Bullhorn and the customer populates them during Bullhorn onboarding. We flag this gap in the migration scope document.

Bullhorn Opportunity is a sales-layer entity for tracking candidate-driven business development, not a recruitment-specific object. Longlist does not have an Opportunity equivalent. If the customer's team uses Bullhorn Opportunities to track placement-fee pipelines, these records are created post-migration. We do not create Opportunity records from Longlist data.

Longlist records carry an owner attribution (the sourcer who created or last edited the record). We resolve Longlist owner email addresses against the Bullhorn User table in the destination org. Any Longlist owner without a matching Bullhorn User is held in a reconciliation queue. The customer's Bullhorn admin provisions any missing Users before record import resumes. Owner resolution is required before Candidate insert because Bullhorn requires an ownerId on all Candidate records.

Longlist email sequences and outreach cadences are automation objects that have no direct Bullhorn equivalent at the individual-sourcer level. Bullhorn's automation layer (Bullhorn Automation) handles outreach at scale but uses a different event and action model. We do not migrate sequences as code. We deliver a written inventory of every active Longlist sequence with its steps, delays, and trigger conditions, mapped to a recommended Bullhorn Automation equivalent for the customer's Bullhorn admin or implementation partner to rebuild.