Migrate from Workable Zone - HRM to Bullhorn ATS & CRM

Workable Candidate records map to Bullhorn Candidate via the Candidate's email address as the dedupe key. Core fields (firstName, lastName, email, phone, address, LinkedIn URL, source, status) migrate directly. Workable's skills, certifications, and custom text fields map to Bullhorn Candidate standard fields or custom fields if the Bullhorn edition supports them. Resume binaries from Workable's bulk export attach to Bullhorn Candidate via the ContentDocument API: we create the Candidate record first, then issue a POST to /file/{entityType}/{entityId}/uploadDocument to attach the binary with the correct ContentDocumentLink.

Workable Employee records (skills, payroll details, department, title, employment status) have no native Bullhorn HRIS equivalent. Bullhorn is an ATS-and-CRM for recruitment agencies and does not include an HR module. We exclude Employee records from standard Bullhorn migration scope and instead deliver a written inventory of all Employee fields, data types, and sample values in a CSV for the customer to onboard into a separate HRMS such as BambooHR, Rippling, or ADP. The customer should select and configure the destination HRMS before migration so that any future Employee-to-Candidate conversion can reference the same person record.

Workable Job postings map to Bullhorn JobOrder. Workable's job status (open, paused, closed) maps to Bullhorn's JobOrder isOpen flag and status field. Workable's departments and offices map to Bullhorn JobOrder categories and businessSector. Workable's pay-rate and employment-type fields map to Bullhorn JobOrder custom fields or standard fields. Active jobs are imported first; archived jobs can be imported in a separate phase or excluded from the primary migration scope.

Workable pipeline stages map to Bullhorn Pipeline stages. Each Workable pipeline becomes a Bullhorn Pipeline with its own stage array. Stage names and order transfer directly; stage probabilities map to Bullhorn's probability percentages rounded to the nearest integer. Bullhorn's Pipeline builder is configured during schema setup before any JobOrder records are imported.

Workable interview scorecards and evaluator feedback migrate to Bullhorn Scorecard records linked to the Candidate and JobOrder. Evaluation ratings and free-text reviewer comments transfer as structured fields on the Scorecard. Bullhorn's Scorecard object is entity-specific and attaches to a Candidate submission for a given JobOrder; we ensure the Scorecard is created after both the Candidate and JobOrder exist in Bullhorn by resolving both IDs before inserting.

Workable Offer records (compensation, start date, offer status, offer letter document) map to Bullhorn Opportunity. The Workable JobOrder ID becomes the parent WhatId on the Opportunity. Compensation fields (salary, bonus, equity) migrate to Bullhorn Opportunity custom fields. The offer letter document migrates as a ContentDocument attached to the Opportunity via ContentDocumentLink. Bullhorn Opportunity stages are configured to reflect the Workable offer lifecycle (offer extended, accepted, declined, rescinded).

Workable Time-Off balances (leave type, balance, accrual rate, used days) have no standard Bullhorn equivalent. Bullhorn does not include a native HRIS or time-tracking module. We exclude Time-Off records from the standard Bullhorn migration scope and deliver them as a structured CSV inventory (employee identifier, leave type, balance, accrual date) with a recommendation to onboard the data into a separate HRMS post-migration. This is a key scoping decision made at the discovery call.

Workable custom properties (text, number, date, dropdown, boolean, multi-select) on Candidates, Employees, and Jobs map to Bullhorn Candidate, JobOrder, or Worker custom fields. Bullhorn Enterprise and Front Office Growth support up to 10 custom objects with 55 fields each; Bullhorn ATS Growth supports 2 custom objects; Bullhorn ATS does not support custom objects. We pre-create the destination custom fields via Bullhorn metadata API before import. Workable custom fields that exceed Bullhorn's field count limits per entity are flagged in scoping and mapped to a custom object or excluded with a written explanation in the migration inventory.

Workable Companies stored in the HR module (the employer side of the organization) map to Bullhorn ClientCorporation if the migration scope includes company records. Workable's company name, website, industry, and address map to Bullhorn ClientCorporation standard fields. For staffing firms, Workable's client companies map to ClientCorporation; for in-house recruiting teams moving to Bullhorn, the Workable HR module company record may represent the employer organization itself and is treated as a ClientCorporation in Bullhorn for consistency.

Workable notes attached to Candidates, Employees, or Jobs migrate to Bullhorn Note records linked via ContentDocumentLink to the parent record. Rich-text notes transfer as Note Body; the original author and timestamp are preserved. Bullhorn Note is subject to the 55-field limit on the parent entity but Note itself is a standard object and does not consume custom object allocation.

Binary attachments from Workable's bulk export (resumes in PDF/DOCX, offer letters, employee documents) migrate as Bullhorn ContentDocument records attached to the parent Candidate, Opportunity (for offers), or Worker record via ContentDocumentLink. Resume files for Candidates use the dedicated /file/{entityType}/{entityId}/uploadDocument endpoint after Candidate creation. We verify each ContentDocument is linked before proceeding to the next batch. Files exceeding Bullhorn's size limits (typically 25 MB per file) are flagged and optionally split or excluded.

Workable Owners referenced on Candidate, Job, and Offer records are resolved to Bullhorn User records by email match. Bullhorn requires every record to have a valid OwnerId at insert time. Any Workable Owner whose email does not exist in the Bullhorn destination org is held in a reconciliation queue; the customer's Bullhorn admin provisions the missing User before we resume migration. We do not create Bullhorn Users on behalf of the customer.

Workable's candidate source field (job board, referral, LinkedIn, direct application) maps directly to Bullhorn Candidate.source. Source values are preserved as-is; if the customer wants to normalize source values post-migration, we flag this as a post-migration admin task in the handoff document.

Workable self-scheduled interview bookings (candidate name, interview type, scheduled time, interviewer, meeting link) map to Bullhorn Event records linked to the Candidate and JobOrder. StartDateTime, EndDateTime, and Location transfer directly. Bullhorn EventRel records are created for each interviewer listed in the Workable interview schedule to preserve the attendee list.