Migrate from Built to Recruit CRM & ATS

Built Employee records map to Recruit CRM Contact or Candidate depending on whether the employee record represents a current team member or a historical placement. We extract each Employee's name fields, title, employment type, start date, and location assignment, then format them into Recruit CRM's standard Contact schema or Candidate profile based on the customer's record-type strategy. Start dates migrate as typed date fields to preserve tenure visibility in Recruit CRM.

For organizations treating current Built employees as Contacts in Recruit CRM (for internal hiring or employee referral workflows), we map Employee email to Contact email as the dedupe key, Employee phone to Contact phone, and Employee address components to Contact address fields. Employment type (full-time, part-time, contractor) maps to a custom Contact field since Recruit CRM's standard Contact schema does not include an employment type property by default.

Built stores manager assignment as a link from one Employee record to another Employee record. Recruit CRM Contact does not have a native manager relationship field. We resolve this during a two-pass import: first loading all Contact base records with a temporary placeholder for the manager reference, then in the second pass resolving the manager Contact ID and writing to a custom Contact field (e.g., reports_to__c) that you configure in Recruit CRM before migration. Circular manager assignments are detected and flagged during the scoping phase so they do not create impossible hierarchies in the destination.

Built Department records represent organizational units that map to Recruit CRM Companies when the department functions as a client organization, or to a custom Contact field (department__c) when the department represents an internal organizational unit. We review the Department schema during scoping to determine the appropriate mapping strategy. Department head information migrates as a Contact reference or custom field depending on the chosen structure.

Built Location records contain office site or remote-work designations. We extract the location name, address, city, state, and country fields and map them to the corresponding Contact address fields in Recruit CRM. If Built uses a hierarchical location model (e.g., Region > Office > Floor), we flatten it into a single address structure and preserve the hierarchy in a custom field for reference. Remote-work designations migrate as a custom field value on the Contact record.

Job title is stored as a free-text field on the Built Employee record. It maps directly to the Contact Title field in Recruit CRM with no transformation required. Title is preserved as entered in Built without normalization, so duplicates (e.g., 'Software Engineer' vs 'Software Engineer ') may require a post-migration dedupe step if Recruit CRM enforces strict uniqueness.

Built tracks employment type as a property on the Employee record with values including full-time, part-time, contractor, and temporary. Recruit CRM's standard Contact schema does not include an employment type field, so we create a custom picklist field (employment_type__c) on the Contact object before migration. The picklist values are seeded from the distinct values found in the Built export, and any unmapped values are flagged for manual review during staging validation.

Built organizations can define custom properties on Employee records. We extract the complete custom field schema at the start of migration by querying the Built API and comparing against standard Employee fields to build a full field list. Each custom field is then created as a matching custom field on the Recruit CRM Contact object, with field type preserved (text, number, date, picklist). Picklist values migrate as option entries in the Recruit CRM custom field configuration. Any custom fields with no clear Recruit CRM equivalent are flagged for explicit mapping during the scoping call.

Employee documents and uploaded files attached to profiles in Built do not appear in the standard data export. This is a documented limitation of Built's export mechanism. If you need attachments migrated, you must request a separate file-level export from Built support. We handle the extracted files as a parallel batch: organized into a folder structure keyed by employee ID, with a mapping spreadsheet linking each file to the destination Contact record. Re-linking is a manual step in Recruit CRM's UI or API because Recruit CRM does not have a native bulk file-to-contact attachment mechanism. We document the re-link procedure and provide the mapping spreadsheet to your team.

The visual org chart is a rendering of underlying employee hierarchy data in Built, not a separate data object. When migrating from Built, we extract the underlying Employee records, Department assignments, and manager relationships. The visual org chart does not have a direct equivalent in Recruit CRM because Recruit CRM is an ATS/CRM rather than an org chart platform. We deliver a written document describing your organizational hierarchy derived from the migrated data, which your team can use to manually configure any org chart widgets or reporting structures in Recruit CRM or a separate org chart tool.