Migrate from Candidate Manager to Crelate

Candidate Manager Candidate records map to Crelate Contact as the primary record. We map name fields (first name, last name, full name), email address (as the dedupe key), phone, address, resume (as a file attachment), application date (as createdAt), source attribution (as a custom text field), and status stage (as a custom picklist preserving the Candidate Manager stage label). Ranking and pre-profiling scores transfer as custom numeric fields. We flag any candidate with multiple applications to the same job as a potential duplicate for reconciliation before bulk import.

Numeric ranking values stored as candidate properties in Candidate Manager transfer to Crelate as custom number fields on Contact. The field name is preserved from the source (e.g., ranking_score, screening_score) as a custom field in Crelate. If multiple ranking fields exist, we map each to a separate custom number field and note that Crelate has no native scoring object; these values land as reference data only.

Candidate Manager Job Orders map directly to Crelate Job Order records. We map requisition title, department, location, open date, and status. Custom fields attached to job orders are discovered during scoping and mapped individually to Crelate custom fields on Job Order. The destination job order is created before candidate import so that the application-to-job lookup relationship is satisfied at insert time.

Candidate Manager uses fixed stage names (Applied, Under Consideration, Interviewing, Hired, etc.) that cannot be reconfigured at the workflow level. We preserve the original stage label as a custom picklist field on the Contact record in Crelate and map it to the nearest equivalent Crelate pipeline stage. Stage probability percentages are not available in Candidate Manager and cannot be migrated; we recommend setting these in Crelate post-migration.

Hiring manager portal records in Candidate Manager carry an owner attribution field that references an entity without necessarily creating a formal user account. We map this attribution to a custom text field or contact role in Crelate linked to the associated Company record. If the hiring manager exists in Crelate as a Contact, we create a Company Role entry; if not, we create a contact with a custom field hiring_manager_source__c set to the original Candidate Manager portal identifier.

Agency submissions tracked in Candidate Manager map to Crelate Company (the agency) and Contact (the agency recruiter) records. The agency name becomes the Company name, and the submission ID is preserved as a custom text field on the Contact record. Any agency-specific notes attached to the candidate submission migrate as a custom long-text field on the Contact. We deduplicate agencies by name during staging and flag cases where the same agency appears under variant spellings.

Candidate Manager onboarding task completion status and document references migrate to Crelate Contact as custom fields and document links. E-signature data and form-fill status do not export cleanly from Candidate Manager and are flagged as manual-reconciliation items post-migration. We create a custom text field onboarding_status__c and a document attachment section for any exported onboarding files. The customer's admin completes e-signature re-collection in Crelate post-migration.

Candidate Manager reporting module generates aggregate hiring funnel data exports. We import these as supplementary records in Crelate—either as custom object rows (if the destination includes custom objects) or as a reference document attachment on the root Job Order. Aggregate metrics (time-to-hire, source effectiveness, pipeline conversion rates) reflect Candidate Manager's historical data and are preserved for reporting continuity rather than live migration into Crelate's analytics engine.

Custom fields at the candidate level in Candidate Manager are discovered during the scoping call by reviewing the reporting module column headers and any visible field labels. Each discovered custom field is mapped to a Crelate Contact custom field of the equivalent type (Short Answer, Long Answer, Picklist, Numeric, Date). Custom field API names in Crelate follow the source field label converted to a slug format (e.g., referred_by becomes referred_by__c). We validate the field type mapping during sandbox staging before production import.

Custom fields at the job order level in Candidate Manager follow the same discovery and mapping process as candidate-level custom fields. We map them to Crelate Job Order custom fields of matching type. The job order custom fields are created before candidate import so that any job-order-attached custom field values on candidate-application join records are resolved correctly during migration.

The candidate-to-job application relationship in Candidate Manager maps to Crelate Candidate Submittal records that link a Contact to a Job Order. We preserve the application date, stage at application time, and any submission notes. The submittal status in Crelate is set to match the Candidate Manager stage at migration. If the candidate was hired, we create a Placement record in Crelate linked to the Job Order and Contact.

Candidate Manager owners referenced on candidate and job order records are resolved by email match against Crelate User records. Any Candidate Manager owner without a matching Crelate User is held in a reconciliation queue; the customer's admin provisions the missing User before record import resumes. Owner-less records (e.g., candidates created via agency portal without an owner assignment) are flagged and mapped to a default migration user or a dedicated agency contact record.