Migrate from Manatal to Bullhorn ATS & CRM

Manatal Candidate records map directly to Bullhorn Candidate. The core profile fields (name, email, phone, address, work history, education) map to Bullhorn Candidate's corresponding standard fields. We preserve Manatal's tags as Bullhorn Candidate tags, resume documents as Bullhorn ContentDocument records linked via ContentDocumentLink, and custom field values into Bullhorn customObject fields (customObject1s through customObject10s) or standard candidate fields depending on what the customer has pre-provisioned through Bullhorn Support. Custom fields require Bullhorn Support to create the custom object schema before we can write to it.

Manatal's per-Job pipeline stage assignments for each Candidate migrate to Bullhorn as JobSubmission records linking Candidate to JobOrder with the current stage recorded. Stage history (all prior stages with timestamps) is preserved as a JSON blob in a Bullhorn custom text area field or as Note records attached to the Candidate for audit. Bullhorn's JobOrder tracks the job's own pipeline stages independently from the candidate's submission status, so we map both the job-stage definition and the candidate-specific submission stage.

Manatal's AI candidate scoring and scorecard categories do not have a direct Bullhorn equivalent as a first-class object. We migrate the numeric scores and scoring category labels as custom fields on the Candidate record (customObject fields or standard numeric custom fields). The scoring model logic (weighting, criteria) is documented separately for the customer's Bullhorn admin to rebuild using Bullhorn's reporting or a third-party AI scoring integration. Bullhorn offers AI resume matching as a paid add-on rather than built-in functionality.

Manatal Job records map to Bullhorn JobOrder. The job title, description, requirements, salary range, and employment type map to standard JobOrder fields. Manatal's configurable pipeline stages per job map to Bullhorn's JobOrder customstatus1 through customstatus5 fields or the job's associated JobSubmission structure. Published status and job board distribution settings from Manatal do not migrate; we document them for manual reconfiguration in Bullhorn.

Manatal's per-job configurable pipeline stages are defined as a named sequence per Job. We map each Manatal stage name to a Bullhorn custom status value on JobOrder (customstatus1-5) and set the corresponding JobSubmission status when we create the candidate-to-job submission records. If Manatal jobs use non-standard stage counts (fewer than 5 or more than 5), we align to the closest Bullhorn customstatus field structure and document any stages that require a Bullhorn custom field for extension.

Manatal Organization records (representing clients or internal departments) map to Bullhorn ClientCorporation. Organization name maps to ClientCorporation name, address to the corporation's address fields, and industry to the industry picklist. We create ClientCorporation records before any Candidate import so that the lookup reference is satisfied at insert time. Manatal's bulk import uses name-only deduplication that silently skips matching names; we preprocess the source dataset to detect and flag or merge duplicate organization names before generating the Bullhorn import file.

Manatal Organization records can contain multiple contact persons within the same organization. We split these into separate Bullhorn ClientContact records and link each to the parent ClientCorporation via the clientCorporation field. ClientContact fields (name, title, email, phone) map directly. If Manatal stores multiple decision-maker roles per organization, each becomes a distinct ClientContact record with its own role and primary flag. This split requires the ClientCorporation to exist first, so we sequence Corporation import before Contact import.

Manatal custom fields on Candidates organized under custom categories map to Bullhorn custom object fields. Bullhorn custom objects must be initially set up by Bullhorn Support via a support ticket before we can write data to them via the REST API. During scoping, we identify every Manatal custom field that requires a Bullhorn custom object, and the customer submits the Bullhorn Support ticket to create the schema. We then write to the API-named equivalents (e.g., customObject1s.text1) using the /meta endpoint to verify field structure before import. Standard-type Manatal custom fields (text, number, date, picklist) map to equivalent Bullhorn standard field types where available.

Manatal activity logs capturing user actions on Candidates and Jobs migrate to a combination of Bullhorn Note, Task, and Event records depending on the action type. Call and meeting activities map to Bullhorn Event with start/end times and attendees. Administrative actions (stage changes, field updates) map to Note records with a timestamp and actor attribution. High-volume activity logs may require chunking due to Bullhorn REST API pagination limits; we use bulk API for large datasets and batch inserts for Notes.

Manatal resume files and candidate attachments are referenced by URL or stored in Manatal's file system. We migrate document metadata (filename, file type, upload date, attached candidate) as Bullhorn ContentDocument records. Binary file transfer depends on Manatal's export capabilities—if the export delivers file URLs, we download and re-upload to Bullhorn's document management via the REST API; if binary export is not available, we document the attachment inventory for manual re-upload post-migration.

Manatal flat-label tags applied to Candidates and Jobs migrate to Bullhorn's tagging system. Bullhorn supports tags on Candidate and JobOrder via the tag field (comma-separated string) or via separate Tag records depending on Bullhorn configuration. We preserve the exact tag names and apply them to the corresponding Bullhorn records during import. If the customer uses a large tag vocabulary (over 200 unique tags), we coordinate tag normalization to avoid field length issues.

Manatal user accounts with roles and permissions are migrated as reference records in Bullhorn. Manatal's internal user ID and role assignments are preserved as custom fields on the Bullhorn Candidate or as a separate User mapping table. Bullhorn User records (active recruiter accounts) are typically provisioned by the customer's Bullhorn admin, not migrated as live user accounts, because Bullhorn user provisioning requires license assignment. We match Manatal users to Bullhorn users by email during the owner reconciliation phase.

Manatal workflow automations trigger on stage transitions, candidate actions, or time-based events. We do not migrate automation logic as code because Manatal automations and Bullhorn workflows use different event models and action types. We deliver a written inventory of every active Manatal automation rule including its trigger, conditions, actions, and the recommended Bullhorn automation equivalent (Bullhorn Automation, herefish, or Bullhorn-native workflow rules). The customer's Bullhorn admin or a Bullhorn partner rebuilds these post-migration.

Manatal's CRM features tracking client relationships, placements, and commission revenue map to Bullhorn Placement records. A Placement in Bullhorn links the hired Candidate to the JobOrder and ClientCorporation, and records the start date, pay rate, bill rate, and commission. Revenue metrics from Manatal migrate as custom fields on the Bullhorn Placement or related Opportunity record. If Manatal stores placement history without a formal JobOrder association, we create Bullhorn JobOrders retroactively to serve as the placement parent record.