Migrate from Built to Crelate

Built Employee records map to Crelate People records. Each Employee's name fields, job title, employment type, and start date migrate as standard or custom fields on the People record. The Employee's unique ID in Built is preserved as a custom field built_employee_id__c for reconciliation. If the organization uses Crelate to track both current employees and candidates, the migrated People records are tagged with a custom status field to distinguish them from recruiting candidates.

Built Department records do not map to a standalone Crelate object because Crelate does not have a native Department object. Instead, we store the department name as a custom picklist field on the People record. The department head assignment (stored in Built as a manager reference) migrates as a separate People-to-People lookup field if Crelate's schema supports lookup relationships on People, or as a custom text field referencing the manager's name if the schema does not support cross-record lookups.

Built Location records represent office sites or remote-work designations. Crelate does not have a native Location object, so we store location as a custom picklist or text field on the People record. We extract the full location schema during scoping and compare it against Crelate's available field types to choose between picklist (for a finite set of offices) or text (for ad-hoc locations). Remote-work designations are preserved as a separate boolean or picklist value in the same field.

Built stores job title as a free-text field on the Employee record. It migrates directly to a custom text field on the Crelate People record. No transformation is required because job title is a standard free-text field in both platforms. If the destination Crelate org uses a standardized job title taxonomy, we can apply a lookup or picklist during migration, but this requires the customer to provide the title standardization map during scoping.

Built tracks full-time, part-time, contractor, and temporary employment types as an enumerated property on the Employee record. These values map directly to a Crelate custom picklist field on People with equivalent values. We verify the destination picklist values during scoping and add any missing values to Crelate before migration so no records land with null employment type.

Built stores manager assignment as an Employee-to-Employee relationship rather than a standalone field. Crelate People records support a Manager reference field pointing to another People record. We perform a two-pass migration: first loading all People base records with name and contact data, then resolving manager references using the destination-assigned People IDs. Circular manager assignments (Employee A manages Employee B who manages Employee A) are detected and flagged before the second pass runs to prevent impossible hierarchies from being created.

Built preserves each Employee's effective start date as a date field. This migrates to a custom date field on the Crelate People record, preserving the original date for tenure calculation and reporting. If Built stores a hire date and a start date (which can differ for conditional hires), we map both to separate custom date fields on People.

Built tracks active and inactive status on Employee records. We map this to a custom picklist field on Crelate People with values for Active, Inactive, On Leave, and Terminated. If the organization uses additional status values in Built (such as a custom probationary status), we add these to the destination picklist during schema creation before migration begins.

Built organizations can define custom properties on Employee records, and these are not always visible in the admin UI without browsing individual profiles. We extract the full custom field schema by querying the Built API at the start of migration and comparing against the standard Employee fields to build a complete field list. Each custom field is created in Crelate as a matching custom field on People before migration begins. Data type mapping follows: text to text, number to number, date to date, and picklist to picklist.

If Built stores organization-level company data (such as the parent organization name or company-level custom fields), this maps to Crelate's Client or Company object if present in the destination Crelate org. We check for the existence of a Company or Client object during scoping and configure the mapping accordingly. If no Company object exists in the destination Crelate configuration, company-level data is stored as fields on the People record.

Built's ADP integration pulls employee data from ADP's export fields, which do not always use the same names as equivalent fields in the destination HRMS. The preferred name field is a documented example: Built surfaces it from ADP but it is not enabled by default and requires a manual toggle in the Imports section of Company Settings. We check this configuration during migration scoping, explicitly enable any ADP fields the customer wants migrated, and create corresponding custom fields in Crelate so the data lands rather than arriving blank.

Built's org chart is a visual rendering of the underlying Employee hierarchy data, not a separate data object. When migrating from Built, we extract the underlying Employee records with manager relationships intact as structured data on People records. The visual org chart itself does not migrate. After cutover, the customer can use Crelate's reporting and People records to rebuild the org chart view using a third-party org chart tool or a manual configuration. The underlying manager-employee relationship data is fully preserved and queryable in Crelate.

Built stores documents and files against Employee profiles, but attachments are not included in the standard API export. This is a documented limitation of Built's export mechanism. If the customer requests attachment migration, we coordinate a separate file-level export from Built support, extract files to a folder structure keyed by employee ID, and re-link them in Crelate as documents attached to the corresponding People records. This is a parallel file batch that runs outside the standard record migration and requires advance coordination with Built support.