Migrate from Back Track Screening to Bullhorn ATS & CRM

Back Track Screening Candidates map to Bullhorn Candidate records as the primary entity. The Candidate record in Bullhorn holds name, contact information, date of birth, and SSN (stored as a masked or encrypted field per Bullhorn's compliance settings). We preserve the candidate's consent and authorization timestamp on the Candidate record and flag it as a required first-class field because FCRA requires disclosure records to precede any screening order initiation.

Back Track Screening Orders bundle a candidate with a specific package of checks and carry status (pending, in-progress, complete), timestamps, and ordering employer reference. Bullhorn does not have a native screening order object; we create custom entity records on the Candidate or store order metadata in structured Note attachments with a consistent taxonomy (order_id, package_type, status, order_date, employer_reference). The customer's admin re-establishes automated order placement through a Bullhorn-native screening integration post-migration.

SSN trace output produces an address history that drives the county-level criminal search scope in Back Track Screening. This is treated as a first-class migration object because if the address history is not preserved, the destination system cannot reconstruct which counties were searched. We store the raw SSN trace result and the derived address list on the Candidate record or in a custom SSN Trace entity, with each address entry tagged with jurisdiction so county criminal records can be validated against the jurisdictions from that list.

Criminal records returned per jurisdiction (county, state, federal) include charge details, disposition, and court references. We map each returned record to its jurisdiction and flag whether the jurisdiction appears in the SSN trace address history. Records that fall outside the SSN trace coverage are flagged as potentially outside the original search scope. Bullhorn has no native criminal record object; we create custom entity records (criminal_record with fields for jurisdiction, charge, disposition, court, search_date, record_date) or store them as structured document attachments on the Candidate.

Education verification results include school name, degree, dates of attendance, and verification status. We preserve the source institution record and verification call notes. Bullhorn's WorkHistory entity is the closest standard object for employment-type history; we create a parallel custom entity for education verifications with fields for school_name, degree, field_of_study, dates, verification_status, verified_by, and verification_notes to preserve the full verification context.

Employment verification results include employer name, title, dates of employment, salary (if disclosed), and reason for leaving. We preserve the raw employer response and map to Bullhorn's WorkHistory entity, setting is_verified = true and storing the verification notes in the description or a custom field. Any salary data is stored in a custom field with FCRA-permissible visibility restrictions.

Drug test records include test type (urine, hair, DOT), collection date, lab result (negative, positive, dilute), and MRO review status. We create a custom drug_test entity on the Candidate with fields for test_type, collection_date, lab_result, mro_status, and dot_flag. DOT-specific tests are flagged for any downstream compliance requirements in Bullhorn.

Credit reports returned for employment purposes under FCRA include only permissible elements (typically bankruptcy and sometimes public records). We strip any non-permissible credit history elements during migration and store only the permissible inquiry content in a custom entity on the Candidate. Bullhorn does not natively display credit report data; this is stored in a restricted-access custom entity with FCRA disclosure visibility controls.

Adverse action documentation under FCRA includes the pre-adverse action notice, the candidate response window, and the final adverse action letter. These are compliance-critical and must be migrated in sequence before screening results so that the employer retains legal defensibility for adverse action decisions. We store them as document attachments on the Candidate record with a consistent naming taxonomy (pre_adverse_action_DATE, response_window_end_DATE, final_adverse_action_DATE) and flag the signed-date timestamp for compliance reconstruction.

Back Track Screening offers customized solutions beyond standard packages, and these vary by client. Each custom check type is treated as a unique custom entity during migration. We document the full schema of every custom check type during scoping, create the corresponding custom entity in Bullhorn with equivalent fields, and migrate the historical results. The customer's admin re-establishes any automated order placement for custom check types through Bullhorn's integration layer.

FCRA consent and disclosure records are mandatory migration objects sequenced before any screening results. Each signed disclosure and authorization record is stored as a document attachment on the Candidate with a signed_date timestamp. We validate that every screening result in the output is preceded by a consent record with an earlier timestamp. Back Track Screening's FCRA classification of each check type (investigative versus consumer report) is preserved as a field on the custom screening order entity so that the customer's legal team can reconstruct the compliance chain.

Back Track Screening orders reference the employer that ordered the screening. We map this to Bullhorn's ClientCorporation entity, which represents the hiring client. ClientCorporation holds the employer name, contact information, and any screening package defaults the client has configured. This entity is created before Candidate records so that the ClientCorporation lookup on any associated screening order metadata is satisfied at import time.