Migrate from Folks HR to Bullhorn ATS & CRM

Folks HR employee records map to Bullhorn Candidate records with a custom field folks_employee_id__c carrying the original Folks HR employee identifier. Contact information (name, email, phone, address) maps to standard Bullhorn Candidate fields. If the customer also licenses Bullhorn CRM, employee records that represent client contacts map to Bullhorn Contact with a type flag. We preserve the original employment status, start date, and department as custom fields on the Candidate record since Bullhorn's native Candidate object does not have dedicated fields for these HR attributes.

Folks HR candidate records map directly to Bullhorn Candidate records with the pipeline stage translated to the corresponding Bullhorn status value (Applied, Phone Screen, Interview, Offer, Placed). Resume files download individually from Folks HR (no bulk endpoint) and upload to Bullhorn as ContentDocument records linked via ContentDocumentLink to the Candidate. We preserve the full application history and interview score entries as notes attached to the Candidate record.

Folks HR job requisitions map to Bullhorn JobOrder records. The job title, description, requirements, and employment type (full-time, part-time, contract) migrate to Bullhorn JobOrder standard fields. Salary range from Folks HR becomes custom fields on the JobOrder since Bullhorn does not have a native salary range field. We resolve the owning recruiter by matching the Folks HR user email against Bullhorn user accounts.

Folks HR leave requests map to Bullhorn's time-off records if Bullhorn Onboarding (formerly Able) is in scope. If Bullhorn Onboarding is not licensed, leave requests migrate as a Bullhorn custom object (LeaveRequest__c) with fields for leave type, start date, end date, status, and employee reference. Leave balance snapshots from Folks HR are stored as a custom field on the Candidate or in a separate accrual table. We flag that Bullhorn's accrual engine must be configured post-migration for ongoing balance calculation.

Folks HR time entries map to Bullhorn TimeCardEntry records if Bullhorn Time & Expense (formerly myPeopleNet) is in scope. If not, they migrate as custom object records (TimeEntry__c) with date, hours, cost code, and employee reference. We export all historical timesheet records and map the cost code association to a Bullhorn custom field or custom object lookup depending on the destination configuration.

Folks HR performance review cycles, review forms, ratings, and reviewer comments are stored as notes or in a custom object (PerformanceReview__c) attached to the corresponding Candidate record in Bullhorn. Bullhorn does not have a native performance review module, so the review data is preserved as structured notes with reviewer name, review date, rating, and comment fields. We discuss the preferred format with the customer during scoping.

Folks HR departments map to Bullhorn BusinessSector as a custom text field on the Candidate record, or to a Bullhorn custom object (Department__c) if the customer requires department-level reporting in Bullhorn. Bullhorn's standard BusinessSector field is a free-text field with no validation, so we coordinate with the customer on whether to use it directly or create a controlled custom object.

Folks HR user accounts map to Bullhorn User records by email match. Role-based permissions (admin, manager, employee) translate to Bullhorn role assignments, though Bullhorn's permission model differs from Folks HR's. Owners without a matching Bullhorn User go to a reconciliation queue, and the customer's Bullhorn admin provisions missing users before record import resumes since Bullhorn requires an owner on every record.

Folks HR employee documents (contracts, tax forms, certifications) download individually via API (no bulk endpoint) and upload to Bullhorn as ContentDocument records linked via ContentDocumentLink to the corresponding Candidate record. For large document archives (hundreds of files), we sequence downloads across multiple sessions to stay within Folks HR's 60 requests per minute API limit and prioritize high-value documents first. We surface this constraint during scoping so the customer can set document prioritization.

Folks HR candidate resumes, offer letters, and recruitment attachments map to Bullhorn ContentDocument records linked to the Candidate or JobOrder. Resume files download individually from Folks HR and attach to the Bullhorn Candidate record with the Description field set to the original Folks HR attachment type (Resume, Cover Letter, Offer Letter, etc.). We preserve the original file name and any Folks HR file ID as metadata for audit trail purposes.

Folks HR custom fields on employee profiles map to Bullhorn custom fields on the Candidate object. Field type translation is determined during scoping: text fields become CustomText1-50, date fields become CustomDate1-10, numeric fields become CustomFloat1-10. Bullhorn has a 100-character limit on CustomText fields that we check against Folks HR source values, truncating or escalating based on customer preference. Bullhorn's edition limits the number of available custom fields per entity, so we prioritize the customer's most critical custom fields during scoping.

Folks HR expense reports with line items, receipts, amounts, and approval status are exported as structured data. Bullhorn does not have a native expense management module. We migrate expense report metadata (report ID, date, total amount, approval status, line item descriptions) to a Bullhorn custom object (ExpenseReport__c) if the customer licenses Bullhorn CRM or ATS with custom objects available. Receipts download individually from Folks HR and are attached as ContentDocument records. If Bullhorn Onboarding with expense features is not in scope, we document the expense data structure for migration to a dedicated expense tool.