Migrate from flair.hr to Recruit CRM & ATS

flair Candidates are stored as Salesforce Leads or custom JobApplication objects depending on the flair configuration. Recruit CRM uses a standard Candidate object for all talent records. We inspect the flair org's object model during discovery to determine whether Candidates map to Leads or to a custom object, then apply the matching mapping. Candidate name, email, phone, address, current company, current title, LinkedIn URL, source, and tags migrate directly. Status and stage values are translated to Recruit CRM's pipeline status equivalents based on a mapping table agreed during scoping.

flair Positions are custom Salesforce objects representing job openings, linked to Departments and Locations with headcount and reporting relationships. Recruit CRM Jobs hold the job title, description, requirements, salary range, location, and status. We preserve the position hierarchy and reporting structure in Recruit CRM's Job object fields, mapping the flair department assignment to a custom field or the job's department tag. Active posting status migrates as the Recruit CRM Job status.

flair Departments represent the organizational unit structure with hierarchy and cost-center assignments. Recruit CRM has no native Department or organizational unit object; departments exist as organizational metadata attached to Jobs and Candidates. We migrate department names as a custom multi-select picklist or tag field on the Job and Candidate records, preserving the full department list from flair for the customer's admin to organize into Recruit CRM's tagging or custom field structure.

flair Locations are custom objects representing physical or legal entity work sites with address, country, timezone, and cost-center assignments. Recruit CRM has a location field on Jobs and a candidate availability field, but no dedicated location object. We map the primary location address, country, and timezone to Recruit CRM's location field and preserve timezone as a custom field for jobs with scheduling requirements.

flair Absence records track leave types, start and end dates, approval status, and linked employee lookups across the full absence history. Recruit CRM has no native absence management module. We migrate absence history as a custom Absence object in Recruit CRM with fields for leave type, start date, end date, status, and the linked candidate or contact reference. If the customer uses Recruit CRM primarily for external candidates, absence records are stored as read-only historical entries in a custom object rather than active absence management.

flair Document storage uses Salesforce Files and ContentDocumentLink, linking resumes, cover letters, certifications, and offer letters to Employee or Position records. Recruit CRM supports file attachments on Candidate records (CV, cover letter, portfolio) and on Job records. We migrate document binaries as attachments on the corresponding Recruit CRM Candidate or Job record, preserving the linking relationship. Large document volumes (over 10,000 files) require batched migration with volume-aware chunking to avoid timeout errors.

flair Employee records are internal HR records with employment details, start dates, manager relationships, compensation, and department assignments stored on Salesforce Contacts with flair custom fields. Recruit CRM is built for external candidates and clients, not internal HR administration. We migrate the subset of flair Employee records that represent external contractors, consultants, or talent-pool candidates as Recruit CRM Candidate records with basic contact details preserved. Internal employee data (compensation, manager relationships, HR-specific fields) is documented as a gap — Recruit CRM has no native internal employee object — and the customer determines whether to use a separate HR system for this data post-migration.

flair Performance Reviews are custom objects tracking review cycles, goals, OKRs, ratings, and feedback linked to Employees. Recruit CRM has no native performance review or OKR module. We migrate review cycle names, review period dates, and aggregate rating scores as records in a Recruit CRM custom Performance_Review object. Individual goal and objective details migrate as line items under the review record. Review workflow step status from flair's Salesforce Flow-based approval sequences is documented as a written inventory for the customer's admin to rebuild in Recruit CRM's workflow builder.

flair Workflows are Salesforce Flow-based step sequences for onboarding journeys, performance review approval chains, and absence escalation. Recruit CRM has its own workflow automation builder for candidate stage progression, email triggers, and task creation. We do not migrate flair Workflows as code because Salesforce Flow and Recruit CRM Workflows are architecturally different. We deliver a written inventory of every active flair Workflow with its trigger conditions, step sequence, and actions, plus a recommended Recruit CRM Workflow equivalent. The customer's admin rebuilds the workflows in Recruit CRM's native builder post-migration.

flair Time Entries use either custom TimeEntry objects or standard Salesforce Event/Task records depending on the deployment version. Recruit CRM does not have a native time tracking module. We detect the underlying flair time tracking model during discovery schema inspection, then map time entry data — hours, date, project code, cost center — to Recruit CRM's Candidate Submission object if the customer uses submissions for contractor billing, or to a custom Time_Entry object we provision during migration. Active time tracking workflows from flair are documented for rebuild in Recruit CRM's workflow builder.

flair's extensibility model uses Salesforce custom objects and fields (accessed via the flair__Extra_Form_Field__mdt and flair__Extra_Table_Field__mdt metadata types) for industry-specific or company-defined data structures. We run a Salesforce schema describe call at the start of every migration to enumerate all custom objects and fields in the customer's flair org. We then pre-create equivalent custom objects in Recruit CRM, including all custom fields, field types, and lookup relationships, before importing any data. Custom object naming follows Recruit CRM's field naming conventions and field type constraints.