Migrate from Factorial to Bullhorn ATS & CRM

Factorial employee records map to Bullhorn Candidate records. We map firstName, lastName, personalEmail, workEmail, phone, jobTitle, department, hireDate, and employmentStatus directly. Custom employee properties discovered during scoping (Factorial has no schema API so we enumerate active fields via the employee endpoint) map to Bullhorn Candidate custom fields. Active employment status from Factorial sets Candidate status to 'Active' in Bullhorn; inactive status maps to 'Archived'. Historical employee records that represent past employees map to Candidates with status 'Placed' or 'Not Active' per the customer's preference.

Factorial organizational hierarchy (departments, cost centers, parent-child relationships) has no direct Bullhorn equivalent because Bullhorn's organizational model centers on ClientCorporations for external companies and does not track internal org structure natively. We map departments to a Bullhorn custom object (Department__c) or to a multi-select picklist on the Candidate record, depending on the customer's reporting needs. Cost centers map to custom fields on Candidate or to a custom object if the customer requires cost-center attribution on Placements.

Factorial employment contracts include contract type (permanent, fixed-term, part-time), working hours, probation period, and legal entity reference. Bullhorn has no native contract entity, so we store contract metadata on Candidate custom fields (contractType__c, workingHours__c, probationEndDate__c) and map the legal entity reference to a ClientCorporation if the legal entity is also a client, or to a custom object (LegalEntity__c) if it is purely an internal entity. Contract templates vary by country and include legally required fields that may not map directly; we flag these during scoping and preserve the raw contract data as a document attachment on the Candidate record.

Historical salary changes, bonuses, and equity grants are stored as effective-dated compensation records on each Factorial employee. Bullhorn stores payRate and billRate on Placements, not on Candidates. We migrate the full compensation timeline to a CompensationHistory__c custom object linked to Candidate, with fields for effectiveDate, baseSalary, currency, bonusAmount, equityGrant, and changeReason. If the customer requires placement billing rates, we also populate Placement custom fields at migration time. Gross-up calculations and tax withholding rules are not migrated because they are destination-system specific.

Factorial absence types, balances, and accrual rules per employee have no native Bullhorn equivalent. We create an Absence__c custom object in Bullhorn with fields for absenceType, startDate, endDate, hoursRequested, hoursApproved, and accrualBalanceAtMigration. Bullhorn ATS supports up to 2 custom objects (ATS Growth) or 10 (Front Office Growth and Enterprise); Absence__c counts toward this limit. Customers on ATS Growth tier who also need CompensationHistory__c may need to consolidate onto a single custom object or upgrade to access additional slots.

Clock-in/out records and timesheets from Factorial include timestamps, employee reference, and project or cost-center tags. Bullhorn does not have a native time-tracking entity. We map time entries to a TimeEntry__c custom object linked to Candidate, with fields for workDate, clockIn, clockOut, hoursWorked, projectCode, and costCenter. For staffing firms that use Bullhorn Placements for temp workers, we map time entries to Placement Time and Expense records if the Bullhorn instance includes Bullhorn's back-office or VMS integration. Factorial time entries with project codes that represent internal projects require a project reference object in Bullhorn if the customer tracks internal project allocation.

Documents attached to Factorial employee records (contracts, IDs, certifications, policies) migrate as ContentDocument records linked via ContentDocumentLink to the corresponding Bullhorn Candidate. Factorial imposes a per-file size limit and does not expose a bulk document download endpoint, so we paginate the documents list via the API and download each file individually. Large document archives (over 10,000 files) can extend migration time significantly. We flag document-heavy migrations during scoping and set expectations for transfer time accordingly. Document naming conventions from Factorial are preserved in the ContentVersion Title field for searchability.

Factorial allows arbitrary custom fields on employee profiles that are not discoverable via a schema API. We enumerate all active custom fields by calling the employee and contract endpoints during scoping discovery, then map each to a Bullhorn Candidate custom field of the equivalent edit type (text, number, date, drop-down). Bullhorn has per-entity custom field limits (exact count varies by edition and field type); if the Factorial instance uses more custom fields than Bullhorn supports on Candidate, we prioritize business-critical fields and map the remainder to the CompensationHistory__c or a supplementary custom object.

Factorial payroll runs include gross compensation, deductions, supplements, overtime, and net pay tied to a specific country legal entity. Bullhorn does not include HRMS payroll. For staffing firms using Bullhorn for temp placement billing, we map gross pay rate from Factorial to Placement billRate1 and billRate2 fields, and map overtime and supplemental pay to custom Placement fields. Tax withholding, social security contributions, and net-pay calculations do not migrate because they must be recomputed in the destination payroll system based on local requirements. We deliver a written payroll data export from Factorial structured for import into the customer's chosen payroll processor.

Factorial stores emergency contact details (name, relationship, phone) on employee profiles. Bullhorn does not have a native emergency contact entity. We create an EmergencyContact__c custom object linked to Candidate with fields for name, relationship, phone, and email. This custom object counts toward the Bullhorn custom object limit and requires Bullhorn Support to provision before data import.

Factorial stores bank account details for payroll disbursement. Bullhorn does not store banking information. We create a BankDetails__c custom object linked to Candidate with fields for bankName, accountNumber (encrypted at rest if Bullhorn edition supports field encryption), routingNumber, and iban. Banking data is migrated under heightened security protocols (encrypted transfer, temporary storage, purge after import confirmation). This data does not belong in Bullhorn's recruitment-focused data model long-term; we recommend the customer move it to their payroll processor as part of cutover.

Factorial workflow objects defining approval chains for time-off, expenses, and documents are platform-specific automation records with no export representation and no Bullhorn equivalent. Bullhorn Automation (a separate licensing tier) provides workflow capabilities but is architecturally different from Factorial's workflow engine. We document the full Factorial workflow structure during discovery including trigger conditions, approver chains, escalation rules, and action outputs, delivered as a written inventory the customer's Bullhorn admin or implementation partner uses to rebuild in Bullhorn Automation or a Bullhorn Partner integration.

Factorial stores qualifications, skills, certifications, and education history on employee profiles. Bullhorn Candidate records support skills (a native text field with comma-separated values or a Skills picklist if configured), and additional qualifications map to Candidate custom fields. Certifications with expiration dates map to a custom Certification__c object linked to Candidate with fields for certificationName, issuedDate, expirationDate, and issuingBody. Skills and qualifications enrichment data sourced from LinkedIn or other platforms in Factorial does not migrate unless stored as structured Factorial custom fields.