Migrate from flair.hr to Bullhorn ATS & CRM

flair Employee records (Salesforce Contacts with flair-specific custom fields) require a strategic decision in Bullhorn. If the customer uses Bullhorn for internal recruiting, employees become Bullhorn Candidates. If the customer uses Bullhorn for external candidate sourcing and already has an HR system for employees, we migrate employee contact data to Bullhorn ClientContact with a custom flaremigration__c flag. We preserve start date as a custom date field, employment status as a custom picklist, and manager relationships by resolving the manager's email to a Bullhorn User lookup. The customer decides the target model during scoping; we cannot make this determination from schema inspection alone.

flair Candidate records (stored as Salesforce Leads or custom JobApplication objects depending on the flair configuration) map directly to Bullhorn Candidate. We inspect the org's object model during discovery to determine whether flair uses Lead or a custom candidate object, then extract the relevant records. Candidate name, email, phone, skills, experience, and source attribution migrate to Bullhorn Candidate fields. Any flair custom fields on the candidate record map to Bullhorn customObject fields if provisioned, or to Candidate custom fields.

flair Position records (job openings) map to Bullhorn JobOrder. The Position title becomes JobOrder.title; the department and location assignments become JobOrder.departments and JobOrder.address; the position status (Open, Closed, On Hold) maps to JobOrder.status. We preserve any custom headcount fields from flair as JobOrder custom fields. JobOrder.clientCorporation is resolved to an existing Bullhorn ClientCorporation or created during migration if no match exists.

flair Departments have no direct Bullhorn equivalent. Bullhorn ClientCorporation represents a client company in the recruiting context, not an internal organizational unit. We offer two migration paths: (1) map Departments to Bullhorn ClientCorporation records if the customer treats departments as client-facing business units in Bullhorn, or (2) document Departments in a custom Bullhorn object (customObject1 through customObject10 depending on edition) with a name and hierarchy field. The customer selects the strategy during scoping.

flair Absence records (custom objects tracking leave types, start/end dates, approval status, and employee lookups) have no native Bullhorn equivalent. Bullhorn is a recruiting ATS and does not track employee absence. We document this as an out-of-scope object and recommend the customer address absence management through a dedicated HR tool, a Bullhorn custom object, or manual processes post-migration. We preserve the full absence history in the migration scope document so that the customer can elect to build a custom object if desired.

flair time tracking data uses either a custom TimeEntry object or standard Salesforce Event/Task records depending on the flair version. Bullhorn has no native time tracking for ATS records. We detect the underlying flair time model during discovery, then either skip the records (documenting them in the scope) or map them to a Bullhorn custom object if the customer has provisioned one. Time entries linked to projects or cost centers cannot be preserved in Bullhorn without a custom integration.

flair documents stored as Salesforce Files and ContentDocumentLink migrate to Bullhorn Candidate or JobOrder attachments. We extract the binary attachment, upload it to Bullhorn via the entity file endpoint, and link it to the target record. Large document volumes require batch processing with Bullhorn API rate-limit handling. We preserve the ContentDocument description and any folder metadata as the Bullhorn file description.

flair Performance review cycles, goals, OKRs, and feedback records (custom objects linked to Employees) have no Bullhorn equivalent. Bullhorn does not track employee performance management as a native feature. We document the existence of these records in the migration scope, export them as a reference CSV for the customer's HR admin, and recommend rebuilding in a dedicated performance management tool or a Bullhorn custom object provisioned by Bullhorn Support.

flair engagement records (calls, emails, meetings, tasks, notes on Candidate and Employee records) migrate to Bullhorn Candidate tasks and events. Call engagements map to Bullhorn Task with TaskSubtype=Call; email engagements map to Note records attached to the Candidate; meeting engagements map to Event records with attendees linked via EventRelation; task engagements map to Bullhorn Task. We resolve the parent Candidate by email match and preserve the original timestamp for activity timeline ordering. Engagement history migration requires Bulk API handling for volumes over 10,000 records.

flair active job postings (custom objects linked to Positions) migrate to Bullhorn JobOrder with isOpen=True and posting dates preserved. The branded career portal pages themselves do not migrate; flair's career portal builder requires flair support intervention to activate and cannot be exported as a portable artifact. We migrate posting content, location assignments, and segment associations as JobOrder fields and custom fields, then document the career portal URL mapping separately for the customer to re-publish in Bullhorn or on a standalone careers site.

flair custom objects built on Salesforce (for industry-specific or customer-defined data) map to Bullhorn custom objects if the customer has provisioned them. Bullhorn custom objects must be requested via Bullhorn Support using a Custom Object Setup Spreadsheet and are limited to 10 per entity (Front Office Growth/Enterprise) or 2 (ATS Growth) with 55 fields each. We inspect flair's custom object definitions during discovery, cross-reference them with the customer's Bullhorn edition, and flag any that exceed Bullhorn's limits for discussion. Migrations requiring more custom objects than the edition supports are scoped as tier upgrades or partial migrations.

flair Workflows implemented as Salesforce Flow step sequences for onboarding, performance reviews, and approvals do not migrate. Bullhorn's workflow builder operates on a different model (step-based recruiting workflows versus record-triggered Flows). We deliver a written inventory of every active flair Flow with its trigger type, conditions, actions, and a recommended Bullhorn workflow equivalent. The customer's admin rebuilds these in Bullhorn's workflow designer post-migration. Workflows are explicitly out of scope as code migration.