Migrate from Talent Pool Builder to Bullhorn ATS & CRM

Talent Pool Builder candidate records map directly to Bullhorn Candidate entities via the Candidate REST endpoint. We map firstName, lastName, email, phone, and address fields to Bullhorn's Candidate.name, Candidate.email, Candidate.phone, and Candidate.address fields. Application status, source attribution, and stage history map to Bullhorn custom fields or candidate properties. Resume files migrate as Bullhorn CandidateAttachments or ContentDocument records attached to the Candidate. Any Talent Pool Builder custom screening fields map to Bullhorn custom fields (created via Bullhorn's Admin Field Mappings interface before migration). We validate email uniqueness as the dedupe key during insert.

Talent Pool Builder job postings map to Bullhorn Job Order. The job title, department, location, and posting date migrate to JobOrder.title, JobOrder.department, JobOrder.address, and JobOrder.dateCreated. Talent Pool Builder pipeline stage configuration maps to Bullhorn's JobOrder.status (Available, Pending, Closed) and a Bullhorn custom field pipeline_stage__c preserving the original stage name. Bullhorn's Job Order is the parent entity for submissions and placements, so it must be inserted before any Application or Opportunity records.

Talent Pool Builder requisitions track hiring manager requests and approval workflows before a job is opened. Bullhorn does not have a native requisition object in all editions; we map requisitions to Bullhorn Job Order records with a custom field requisition_status__c set to Pending while the approval workflow is active. If the customer uses Bullhorn's approval workflow features, we configure the requisition as a pre-opening Job Order linked to the hiring manager via a Bullhorn custom lookup field. Requisition approval routing does not migrate as automation; we document the existing routing logic for the customer's Bullhorn admin to configure post-migration.

Talent Pool Builder talent pools are segmented candidate lists for long-term engagement. Bullhorn does not have a native talent pool object but supports equivalent segmentation through Candidate Tags and Candidate Lists (Bullhorn List entity). We export pool membership and pool-specific tags, then create Bullhorn Tags (applied to Candidate records) and Bullhorn Candidate Lists for pools that require bulk outreach capability. Pool-specific custom fields migrate to Bullhorn custom fields on the Candidate record.

Talent Pool Builder application records link a Candidate to a Job with a timestamp and stage. Bullhorn models this relationship through a Candidate record linked to a Job Order via the CandidateSubmission (or Submission) entity in Bullhorn ATS/Staffing. We map the application timeline, including stage transitions and recruiter notes, to the Candidate record's custom history fields and to notes attached to the submission. The application timestamp becomes the CandidateSubmission.dateSubmitted.

Interview scheduling data and scores from Talent Pool Builder map to Bullhorn Candidate records with a Bullhorn custom field interview_score__c and interview_date__c. Free-text interview notes migrate as Bullhorn Note records attached to the Candidate entity via ContentDocumentLink. Bullhorn Interview Scheduling and Bullhorn's built-in interview scorecards can be configured post-migration using the interview data we preserve as a reference. We note any source field that exceeds Bullhorn's 32,768-character Note body limit for manual splitting.

Talent Pool Builder offer records include template placeholders, offer status, and digital signature state. Bullhorn does not have a native offer object but models the offer-to-placement stage through Opportunity with custom fields offer_status__c, offer_amount__c, and offer_template__c. We export the offer data and flag the digital signature status as a Bullhorn custom field signature_status__c for post-migration follow-up. Actual placement records in Bullhorn are modeled as Placement (a staffing-specific entity) that links the Candidate, Job Order, and Client Corporation; we preserve the offer-to-acceptance flow as a state transition documented in the Opportunity custom fields.

Talent Pool Builder accounts frequently create custom fields for screening answers, rating scores, source tracking, and compliance data. These fields vary significantly by account. We request a full Talent Pool Builder field inventory during scoping, then create equivalent Bullhorn custom fields via the Admin Field Mappings interface (Admin > Field Mappings in Bullhorn) or Bullhorn Custom Objects for complex multi-field structures. Bullhorn's Custom Object architecture allows up to 10 searchable custom objects with 55 fields each on Growth/Enterprise tiers, or 2 custom objects on Bullhorn ATS. We configure the schema before migration and map data type mismatches (e.g., Talent Pool Builder free-text to Bullhorn drop-down) to the closest Bullhorn field type, flagging any data that does not fit for manual remediation.

Talent Pool Builder email, SMS, and call logs attached to candidate records migrate to Bullhorn Note records linked to the Candidate entity. Bullhorn supports Note with a body (up to 32,768 characters) for communication content. Bullhorn's communication tracking features (email sync, SMS integration) can be activated post-migration to capture new communications going forward. We flag communication thread continuity gaps in the scoping report because the chronological thread context may not be preserved in a flat-note export from Talent Pool Builder. Any thread gaps are documented for the customer's hiring managers who rely on conversation history.

Resume files and uploaded documents from Talent Pool Builder migrate as Bullhorn CandidateAttachment records (the Bullhorn-native resume attachment) or ContentDocument records via Bullhorn's Salesforce-backed document management. File naming conventions vary by Talent Pool Builder account and are preserved as-is. We document the original file name and upload date on a Bullhorn custom field for reference. Bullhorn's resume parsing activates on import if the Bullhorn Resume Parsing integration is enabled on the destination account.

Talent Pool Builder's union compliance flags and seniority-based ranking features are platform-specific and do not map to standard Bullhorn objects. We export the raw seniority_date and union_membership fields as Bullhorn custom date and checkbox fields on the Candidate record. Bullhorn does not activate union compliance or seniority ranking logic natively; the customer's IT or legal team configures any required compliance automation in Bullhorn as a post-migration step. We document the original Talent Pool Builder flag values and their meanings to support the compliance configuration.

Talent Pool Builder recruiter owners attached to candidate, job, and application records map to Bullhorn User entities. We resolve owners by email match against the Bullhorn destination User table. Any Talent Pool Builder owner without a matching Bullhorn User goes to a reconciliation queue for the customer's Bullhorn admin to provision before record import resumes. Migration cannot proceed past this step because Bullhorn User references are required on Job Order and Candidate records.