Migrate from Candidate Manager to BambooHR

Hired candidates from Candidate Manager map to BambooHR Employee records with a corresponding Applicant record to preserve the pre-hire application history. Candidates who were not hired map to BambooHR Applicant records only. We map firstName, lastName, homeEmail, mobilePhone, and address fields using BambooHR's standard field names. The original application date from Candidate Manager becomes the hireDate only for candidates with a Hired stage; non-hired candidates retain the application date as a custom field since BambooHR's Applicant records do not expose a submittedDate in the standard schema.

Candidate Manager's fixed stage names (Applied, Under Consideration, Interviewing, Hired) do not have a direct BambooHR equivalent because BambooHR's ATS module uses a free-form application status field rather than a fixed pipeline model. We preserve the original stage label as a custom text field named original_ats_stage__c on the Applicant record. For hired candidates, we map the Hired stage to the BambooHR employmentStatus field and set the hireDate.

Candidate Manager stores numeric ranking and screening scores as candidate properties. These transfer as-is into custom number fields in BambooHR, prefixed with original_ats_ (e.g., original_ats_ranking_score__c). BambooHR supports numeric custom fields on both Employee and Applicant records. We create these fields during schema setup and populate them for every candidate that carries a score. Note that BambooHR's custom field IDs must be fetched via GET /v1/meta/fields per customer account and cannot be hardcoded.

Candidate Manager job orders carry requisition metadata (department, location, open date, hiring manager). We map these to BambooHR Job records, with the job title becoming the position name, the department mapping to BambooHR's departmentId (pre-created during scoping), and the job open date mapped to the job posting date. Custom fields attached to job orders in Candidate Manager become custom fields on the BambooHR Job record, discovered and mapped individually during the scoping call.

Records created via Candidate Manager's hiring manager portal carry an owner attribution field. We preserve this as a supervisor reference on the corresponding BambooHR Employee record. The BambooHR API field for supervisor is supervisor, which takes an Employee ID. If the hiring manager does not have an Employee record in BambooHR (because they are not an employee), we store the name in a custom text field original_ats_hiring_manager__c and flag it for manual reconciliation.

Agencies submitting candidates through Candidate Manager's staffing portal are tracked as submission sources with agency name and submission ID. BambooHR has no native staffing agency field. We create custom fields original_ats_agency_name__c and original_ats_submission_id__c on the Applicant record and populate them from Candidate Manager's submission source data. Agency-specific notes attached to submissions migrate to original_ats_agency_notes__c.

Candidate Manager extends into onboarding for hired candidates, storing task completion status and document references. BambooHR's onboarding module handles new hire tasks with its own task schema. We migrate onboarding task status as custom fields on the BambooHR Employee record (e.g., original_ats_onboarding_completed__c as a checkbox) and document references as notes or file attachments via BambooHR's employee file API. E-signature status does not transfer cleanly from Candidate Manager since that data is not exported in a structured format.

Candidate Manager's reporting module generates aggregate hiring funnel exports. These do not map to a native BambooHR object because BambooHR's reporting module uses its own data model built on employee records. We deliver the historical hiring funnel data as a supplementary CSV that the customer can import into BambooHR as a custom report or store as an archived reference. BambooHR does not support aggregate ATS funnel reporting natively.

Custom fields at the candidate level in Candidate Manager are not documented in a machine-readable schema and must be discovered during the scoping call. We map each to a BambooHR custom field with a matching data type (text, number, date, dropdown). BambooHR custom fields are fetched per account via GET /v1/meta/fields and are referenced by numeric field ID in API calls. Custom field creation happens in BambooHR before data load begins.

Custom fields at the job order level in Candidate Manager (e.g., approved salary range, headcount approved, employment type) map to custom fields on the BambooHR Job record. We create these during BambooHR schema setup, matching data types. BambooHR Job custom fields use the same custom field ID pattern as Employee custom fields and are discovered via the same /v1/meta/fields endpoint.