Migrate from Longlist to Crelate

Longlist candidate profiles (the primary record surfaced by the Chrome extension) map to Crelate Contact. We pre-process the Longlist export to split the composite candidate record into named fields: firstname, lastname, email, phone, linkedin_url, and source_url. Crelate's Contact record requires at minimum a Last Name; records with no name but an email are imported as Contact with the name field populated from the email local-part and a custom notes field flagging the name gap for manual enrichment.

Crelate supports an optional Candidate sub-record attached to Contact for ATS-specific candidate tracking (application status, source, rating, availability). We create a Crelate Candidate record linked to each migrated Contact when the Longlist record includes application-stage data, source attribution, or sourcer rating fields. This is a configurable mapping; the customer chooses during scoping whether Candidate sub-records are created for all migrated records or only those with explicit application data.

Longlist's enriched email, phone, and LinkedIn URL fields map directly to Crelate's standard Contact fields: email, phone, linkedin_url. We preserve the enrichment source (the website or database Longlist used to surface the contact) as a custom field called original_enrichment_source__c for audit and compliance.

Longlist's tag and list membership data (applied by the sourcer during research) maps to Crelate's Contact Tag system. We create a tag record for each distinct Longlist list or tag and attach it to the corresponding Contact. Tags are non-hierarchical in Crelate; if Longlist had nested list structures, we flatten them to a single tag string and note the hierarchy path in a custom field list_path__c.

Longlist enrichment fields that do not map to a Crelate standard Contact field (for example, company_headcount, seniority_level, tech_stack, or any proprietary sourcer-added field) are routed to Crelate custom fields created before migration. We map Longlist's field data types to Crelate's custom field types (Short Answer for text, Picklist for controlled values, Date for timestamps, Numeric for numbers). Crelate's Business tier supports up to 10 advanced custom fields; Crelate's Business Plus tier increases this limit. We flag any migration that requires more than 10 custom fields for the customer's admin to confirm the tier before import.

Longlist captures the source page or URL from which a contact was enriched (for example, a LinkedIn profile URL or a company directory page). We store this in a custom text field source_url__c on the Crelate Contact for compliance and audit. This field is distinct from linkedin_url and captures the full context of where the contact data was found.

Longlist records carry a capture or enrichment timestamp. We map this to Crelate's Contact CreatedDate when it represents the original record creation in Longlist, and to a custom date field enrichment_date__c when it represents the specific enrichment event rather than the record creation date. We flag this distinction during scoping based on the customer's data retention requirements.

Longlist organizes candidates into named lists or groups that represent a sourcing campaign or talent pool. We map each distinct Longlist list name to either a Crelate Tag (recommended for fewer than 50 distinct lists) or a custom picklist field talent_pool__c with each list name as a picklist value. The customer chooses the strategy during scoping. Multi-list memberships on a single candidate are handled as multiple tag attachments or a multi-select picklist depending on the chosen approach.

Longlist candidate records often include an employer or current company name from the enrichment data. We create a Crelate Company record for each distinct company name found in the Longlist export, then link the Contact to the Company via a lookup. This requires a two-phase import: Companies first, then Contacts with the CompanyId resolved. Companies with no additional data (no address, no industry) are created with name only and flagged for the customer to enrich post-migration.

Any notes or comments the sourcer added inside Longlist to a candidate record migrate as Crelate Contact Notes. Notes are attached to the Contact via ContentDocumentLink. We preserve the original note body, the sourcer's name (mapped to a custom field added_by__c if the sourcer is not a Crelate User), and the original creation timestamp.

If the Longlist export includes a candidate status field (active, passive, contacted, not_interested), we map it to a Crelate custom picklist field candidate_status__c on the Contact or Candidate object. Crelate's standard Contact object does not have a native availability field; the customer selects which object carries this field during scoping.

Crelate enforces email-based duplicate detection by default. We run a pre-migration duplicate check against any existing Crelate Contacts using the email address as the dedupe key. Longlist records matching an existing Crelate Contact are flagged for the customer's review: options include skipping the record, merging into the existing Contact, or overwriting with Longlist data. This step is required before any insert to prevent duplicate Contact records in Crelate.