Migrate from Folks HR to Recruit CRM & ATS

Folks HR Candidate records map directly to Recruit CRM Candidate profiles. We extract full candidate data including name, contact information, resume file, application status, interview scores, and the complete hiring stage history including all status transitions and timestamps. The Folks HR candidate ID is preserved in a custom field folks_hr_id__c on the Recruit CRM Candidate for cross-system audit. Resume files are downloaded individually (no bulk endpoint in Folks HR) and re-attached to the corresponding Recruit CRM Candidate record during the document migration phase.

Folks HR job requisition records map to Recruit CRM Job postings. We transfer job title, job description, department assignment, status (open, filled, on hold), and the date the requisition opened. Candidate-to-job associations are preserved as Recruit CRM Applications linked to the Job and the Candidate. If Folks HR stores job requirements as structured fields, we map them to the Recruit CRM job custom fields; unstructured rich-text requirements migrate as the job description body.

Each Folks HR application-to-requisition record maps to a Recruit CRM Application. The application status in Folks HR (applied, screening, interview, offer, hired, rejected) maps to the nearest Recruit CRM pipeline stage. We preserve the application date, the assigned recruiter, and any interview score or rating recorded against the application in Folks HR as notes or custom fields on the Recruit CRM Application.

Folks HR departments map to Recruit CRM Company records when the migration scope includes client or employer organization data. The Folks HR department name becomes the Company name, and the department manager assignment becomes the primary contact on the Recruit CRM Company. If Folks HR stores client companies separately from internal departments, we separate them during scoping so internal org units and external clients do not collide in the Recruit CRM Company list.

Folks HR user accounts with role-based permissions (admin, manager, employee) map to Recruit CRM user accounts. We extract all active and recently inactive user records with their email, name, role assignment, and access level. Role names differ between platforms: Folks HR admin maps to Recruit CRM Admin, manager to Recruit CRM Recruiter, and employee to Recruit CRM Limited User. The customer's Recruit CRM admin provisions matching accounts before the migration cutover so OwnerId lookups resolve correctly on all candidate and job records.

Folks HR stores candidate resumes, offer letters, and supporting documents as individual file attachments accessible by ID via the API. Recruit CRM accepts document uploads attached to Candidates, Jobs, and Applications. We download each file individually from Folks HR (no bulk download endpoint), preserve the original filename and MIME type, and upload to the corresponding Recruit CRM record. For migrations with hundreds of documents, this extends the timeline materially; we prioritize resume files and most-recent offer letters and flag the document download cycle during scoping.

Folks HR custom field definitions and values on candidate profiles, job records, and employee objects are exported via API. We map each custom field to a corresponding Recruit CRM custom field, matching field types where possible (text to text, date to date, dropdown to picklist). Fields with no equivalent in Recruit CRM are flagged in the mapping document for the customer to either drop or create a new Recruit CRM custom field before migration. Field type mapping requires manual review because Folks HR and Recruit CRM use different type taxonomies.

Folks HR Employee records have no direct equivalent in Recruit CRM because Recruit CRM is a recruitment agency platform, not an HRIS. Employees who are also active candidates in the Folks HR recruitment pipeline migrate as Recruit CRM Candidates. Former employees or internal staff with no recruiting relationship migrate as Recruit CRM Contacts in the client's company list, with a custom field folks_hr_employee_id__c for record linkage. We apply this split based on the employee's current recruiting status in Folks HR at migration time.

Folks HR leave types, accrual rules, and current balance snapshots have no natural home in Recruit CRM. Recruit CRM is purpose-built for recruitment workflows and does not expose a leave management object. We export the current leave balance snapshot per employee and the complete leave request history (dates, leave type, status, approver) as a structured CSV file delivered alongside the migration. The customer's HR team uses this file to enter balances manually in their chosen HR system, or accepts archive-only status for historical leave data.

Folks HR time entries with date, hours, cost code, and employee association cannot migrate to Recruit CRM because Recruit CRM has no timesheet or time tracking object. We export the complete historical timesheet archive as a structured CSV file with employee name, date, hours, and cost code. This file is delivered alongside the migration for the customer's finance or HR team to archive in a separate system or spreadsheet. We flag this gap explicitly during scoping so it does not surface as a surprise post-migration.