HRMS migration
Field-level mapping, validation, and rollback between Back Track Screening and Crelate. We move data and schema; workflows are rebuilt natively in Crelate.
Back Track Screening
Source
Crelate
Destination
Compatibility
9 of 12
objects map 1:1 between Back Track Screening and Crelate.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Back Track Screening to Crelate is a platform consolidation, not a simple record copy. Back Track Screening is a standalone FCRA-compliant background check platform built around modular screening packages, address-driven criminal search scope, and compliance-critical consent and adverse action documentation. Crelate is an ATS and talent management platform that can store screening records as custom objects but requires a custom schema build to replicate Back Track's data model. We extract candidate profiles, screening results, SSN trace output, and compliance records from Back Track; design and provision the matching custom objects in Crelate; and load everything in FCRA-correct sequence. We do not migrate screening workflows or vendor-specific integrations as code; we deliver a written inventory of what the customer's admin must rebuild or reconfigure at Crelate.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Back Track Screening object lands in Crelate, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Back Track Screening
Candidate
Crelate
Person (Contact)
1:1Back Track Screening candidate records containing name, date of birth, SSN, address, and contact information map to Crelate Person records (the Contact entity). SSN is stored as a masked reference per our handling protocol. We preserve the candidate's address history so that county criminal jurisdiction coverage can be validated against the original jurisdictions that were searched. Consent and disclosure records are linked as separate custom object records against the Person.
Back Track Screening
Screening Order
Crelate
Custom Object: Screening Order
1:1Each Back Track Screening order bundles a candidate with a specific package of checks, carrying order status (pending, in-progress, complete) and timestamps. We map this to a Crelate custom object (Screening_Order__c) with fields for package type, status, order date, completion date, and a lookup to the Person record. Package types from Back Track map to Crelate custom picklist values representing the screening types in scope.
Back Track Screening
SSN Trace
Crelate
Custom Object: SSN Trace
1:1Back Track SSN trace output produces an address history for the candidate, which determines county-level criminal search scope. We preserve the raw trace result and the derived address list as a custom object (SSN_Trace__c) linked to the Person, because this data drives the validity of every criminal record returned. We validate that each criminal record in the output is matched to a jurisdiction from the SSN trace address list during migration reconciliation.
Back Track Screening
Criminal Records
Crelate
Custom Object: Criminal Record
1:manyCriminal records returned per jurisdiction (county, state, federal) from Back Track map to Crelate Criminal_Record__c custom objects. Each record includes charge details, disposition, court references, and jurisdiction. We link each record to the SSN_Trace__c custom object that authorized the search scope. Records marked as unverified or for which the employer did not authorize a search are flagged in a verification_status field for compliance review.
Back Track Screening
Education Verification
Crelate
Custom Object: Education Verification
1:1Education verification results include school name, degree, dates of attendance, and verification status. We map these to Crelate Education_Verification__c custom objects linked to the Person record, preserving the source institution record and verification call notes in a long-text area field. Verification status values (verified, unable to verify, refused) map to custom picklist values in Crelate.
Back Track Screening
Employment Verification
Crelate
Custom Object: Employment Verification
1:1Employment verification results include employer name, title, dates of employment, salary (if disclosed), and reason for leaving. We preserve the raw employer response in a long-text field and map structured fields to Crelate Employment_Verification__c custom objects. Any additional documentation (W-2, pay stub references) provided during the Back Track process is stored as attachments or document links on the custom object.
Back Track Screening
Drug Test Record
Crelate
Custom Object: Drug Test Record
1:1Drug test records include test type (urine, hair, DOT), collection date, lab result (negative, positive, dilute), and MRO review status. We map these to Crelate Drug_Test__c custom objects with fields for test type, collection date, result, and MRO status. We note whether the test was DOT-regulated in a boolean field since DOT-regulated tests carry different reporting requirements.
Back Track Screening
Credit Report
Crelate
Custom Object: Credit Report
1:1Credit reports returned for employment purposes include only permissible inquiry elements under FCRA (bankruptcy, public records). We strip any non-permissible credit history before loading into Crelate per FCRA permissible purpose rules. The resulting record is stored as Credit_Report__c with bankruptcy flag, public records flag, and report date. The full credit file is not migrated; only the employment-permissible subset.
Back Track Screening
Adverse Action Record
Crelate
Custom Object: Adverse Action Record
1:1Adverse action documentation includes the pre-adverse action notice, the candidate response window, and the final adverse action letter. We migrate these as separate custom object records (Adverse_Action__c) linked to the Screening_Order__c, with fields for notice date, response deadline, final action date, and action taken. Signed-date timestamps are preserved so the compliance window can be reconstructed at Crelate. This is the highest-severity object in the migration scope because missing or out-of-sequence adverse action records eliminate legal defensibility.
Back Track Screening
FCRA Consent and Disclosure Record
Crelate
Custom Object: FCRA Disclosure
1:1Signed FCRA consent and disclosure records are compliance-critical under the FCRA and must be retained for each candidate screened. We migrate these as Disclosure__c custom object records linked to the Person, with the signed-date timestamp preserved as a first-class field. These records must migrate before any screening results to maintain the legal defensibility chain. We flag any candidate missing a consent record for the customer's HR team to address before adverse action is considered.
Back Track Screening
Custom Check Type
Crelate
Custom Object: Custom Check
1:manyBack Track Screening offers customized solutions beyond standard packages, including industry-specific verifications or unusual search scopes. Each custom check type becomes a Crelate custom object (Custom_Check__c) with fields for check name, scope, result, and status. We create the Crelate custom object schema to match the specific fields present in each custom check rather than applying a generic template, because custom checks by definition do not follow a standard structure.
Back Track Screening
Screening Package Definition
Crelate
Custom Object: Screening Package
lossyBack Track's modular screening packages (standard, enhanced, comprehensive, or client-defined bundles) define which check types are included per order. We map package definitions to a Crelate Screening_Package__c configuration object that lists the included check types. This configuration object drives reporting on screening scope across the migrated candidate pool and supports package-level analytics in Crelate's reporting engine.
| Back Track Screening | Crelate | Compatibility | |
|---|---|---|---|
| Candidate | Person (Contact)1:1 | Fully supported | |
| Screening Order | Custom Object: Screening Order1:1 | Fully supported | |
| SSN Trace | Custom Object: SSN Trace1:1 | Fully supported | |
| Criminal Records | Custom Object: Criminal Record1:many | Mapping required | |
| Education Verification | Custom Object: Education Verification1:1 | Fully supported | |
| Employment Verification | Custom Object: Employment Verification1:1 | Fully supported | |
| Drug Test Record | Custom Object: Drug Test Record1:1 | Fully supported | |
| Credit Report | Custom Object: Credit Report1:1 | Fully supported | |
| Adverse Action Record | Custom Object: Adverse Action Record1:1 | Fully supported | |
| FCRA Consent and Disclosure Record | Custom Object: FCRA Disclosure1:1 | Fully supported | |
| Custom Check Type | Custom Object: Custom Check1:many | Fully supported | |
| Screening Package Definition | Custom Object: Screening Packagelossy | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Back Track Screening gotchas
FCRA consent and disclosure records are compliance-critical in migration
SSN trace address history drives the scope of county criminal searches
Background check industry has a pattern of hidden fees absent from base pricing
Crelate gotchas
120 req/min API rate limit throttles bulk migrations
20 custom field per-entity cap forces data model decisions
15,000-record export ceiling on single operations
Sequences and automation workflows do not migrate
API key is a querystring parameter, not a header
Pair-specific challenges
Migration approach
Discovery and data export coordination
We audit the Back Track Screening account across candidate volume, screening order history, check type distribution, and the presence of adverse action records and consent documentation. We request a full data export from Back Track Screening's team and validate completeness against the candidate list. We confirm the customer's Crelate tier (Business, Business Plus, or Enterprise) and identify whether the background screening module is in scope. The discovery output is a written migration scope document, a data completeness report from Back Track, and a Crelate tier recommendation if the current plan does not support the required custom objects.
Crelate custom object schema design and deployment
We design the Crelate custom object schema to mirror the Back Track Screening data model: Screening_Order__c, SSN_Trace__c, Criminal_Record__c, Education_Verification__c, Employment_Verification__c, Drug_Test__c, Credit_Report__c, Adverse_Action__c, Disclosure__c, Custom_Check__c, and Screening_Package__c. Field types are mapped to Crelate-supported types (text, picklist, date, boolean, long-text area, lookup). Schema is deployed to a Crelate sandbox for validation before production deployment. The customer's Crelate admin approves the schema before we proceed.
Data extraction, transformation, and mapping
We receive the Back Track data export and transform it into the Crelate custom object format. SSN trace address histories are parsed and linked to criminal records for jurisdiction validation. FCRA consent records are separated from result data and flagged for first-phase loading. Adverse action records are tagged with signed-date timestamps. Criminal records are validated against the SSN trace address list and any without a matching jurisdiction are flagged as outside-scope. Education and employment verifications are parsed for structured fields versus raw call notes.
Sandbox migration and compliance sequence validation
We run a full migration into the customer's Crelate sandbox. The HR compliance lead spot-checks candidate records, validates that consent records precede screening results in the timeline, confirms adverse action documentation is complete for any candidate with an adverse action flag, and reviews the criminal record jurisdiction mapping. Any schema corrections, mapping adjustments, or missing data flag resolutions happen in the sandbox phase. The customer signs off on the sandbox migration before production begins.
Production migration in FCRA-correct sequence
We run production migration in compliance-correct order: FCRA Disclosure records first (consent and authorization with signed-date timestamps), then candidate Person records, then SSN Trace address histories, then screening results (criminal, education, employment, drug, credit) linked to the SSN trace, then adverse action records linked to the screening orders. Each phase emits a row-count reconciliation report before the next phase begins. The customer freezes new Back Track orders during the cutover window.
Cutover, validation, and screening workflow handoff
We perform a final delta migration of any records modified during the cutover window, then mark Crelate as the system of record for candidate screening data. We deliver a written inventory of any screening workflows, package configurations, or vendor-specific integrations that require rebuild or reconfiguration in Crelate's background screening module. We support a one-week hypercare window for reconciliation issues. We do not configure Crelate's screening order workflow, configure background check vendor integrations, or rebuild adverse action templates as part of standard migration scope.
Platform deep dives
Back Track Screening
Source
Strengths
Weaknesses
Crelate
Destination
Strengths
Weaknesses
Complexity grading
Standard HRMS migration. 1 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Back Track Screening and Crelate.
Object compatibility
1 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Back Track Screening: Not publicly documented.
Data volume sensitivity
Back Track Screening doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Back Track Screening to Crelate migration scoping. Not seeing yours? Book a call.
Walk through your Back Track Screening to Crelate migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Back Track Screening
Other ways to arrive at Crelate
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.