Migrate from Hireology to Crelate

Hireology Jobs map directly to Crelate Job records. The Job title, description, department, and location fields map cleanly. Hireology's Location object does not have a direct Crelate equivalent; we map the location name to a Crelate Job location field and reassociate any location-specific hiring manager to a Crelate User assignment on the Job. If the customer has multiple Jobs at the same physical location, those remain separate Job records in Crelate rather than a shared Location reference.

Hireology Candidate records map to Crelate Contact records. The core profile fields (name, email, phone, address, resume) migrate directly. Hireology does not expose a unified custom field registry; we discover any custom fields on Candidate records during the discovery phase by sampling a representative set of records and comparing the payload against the standard schema. Discovered custom fields map to Crelate Contact custom fields created before migration.

Hireology Applications link a Candidate to a specific Job at a specific location and carry the application date, current stage, and stage-change history. We map Application records to Crelate as Job Submission activity records linked to the corresponding Contact and Job. The application stage in Hireology maps to a Crelate workflow stage on the Job Submission. Stage-change timestamps are preserved as activity log entries on the submission record.

Hireology interview scorecards are sub-objects on the Application with per-question ratings, free-text comments, and reviewer assignments. Crelate does not have a native scorecard object with variable rubric support; we map scorecards to Crelate Activity Forms configured to match the Hireology rubric, or to structured Note records with a consistent format that captures question, rating, and reviewer. Because Hireology allows different scorecard rubrics by location and job type, we normalize to a single target rubric agreed upon with the customer during scoping. Location-specific nuance that cannot be represented in the normalized rubric is documented in a supplementary notes field on each migrated scorecard.

Hireology stores background check results as structured metadata (pass/fail, check type, date, provider) linked to the Candidate or Application. We migrate this metadata to Crelate as custom fields on the Contact or Job Submission. The actual background check report documents are not downloadable via Hireology's API and do not migrate; candidates who have completed background checks may need to re-initiate screening in Crelate, which we flag during scoping so the customer can plan for onboarding delays on roles requiring verified credentials.

Hireology allows custom fields to be added to Jobs, Candidates, and Applications with no public API registry. During discovery, we run a targeted record scan across a representative sample of each object type, extract all fields present in the sample that are not part of the standard Hireology schema, and compile a custom field inventory. Each discovered custom field is created as a typed custom field in Crelate (text, number, date, picklist, or checkbox) before migration. Fields with no data in the sample are flagged as potentially empty and excluded unless the customer confirms they contain historical data.

Same discovery methodology as Job custom fields applies to Candidate custom fields. We sample a representative set of Candidate records, identify fields outside the standard schema, create corresponding custom fields in Crelate on the Contact entity, and map the data during migration. Multi-select or checkbox-style custom fields in Hireology map to Crelate multi-select picklist or checkbox fields respectively.

Application-level custom fields discovered during the record sampling phase map to custom fields on the Crelate Job Submission entity. Application-level custom fields typically capture prescreen survey responses, EEOC data, or role-specific qualification flags that belong on the submission record rather than the Contact.

Hireology Location records represent individual franchise or retail sites with their own hiring managers and configurations. Crelate does not have a separate Location object; we map the location name to a text or address field on the Crelate Job record. The hiring manager associated with the Location in Hireology maps to a Crelate User assignment on the Job or as a pipeline collaborator. Multi-location organizations with hundreds of sites should confirm during scoping whether they need a separate location taxonomy built in Crelate via a custom object.

Hireology Users (admins, hiring managers, recruiters) with role-based permissions map to Crelate User accounts. We resolve by email match. Multi-location role hierarchies in Hireology (where a regional manager oversees multiple site-level hiring managers) are translated to Crelate team or group structures if the customer requires it; otherwise each Hireology user becomes a standalone Crelate User with a role assignment corresponding to their Hireology role.

Hireology's SkillSurvey integration stores reference check results as part of the Candidate record. We migrate the structured result metadata (reference type, score, completed date, overall recommendation) as custom fields on the Contact or as structured notes. The actual SkillSurvey report document is not accessible via Hireology's API and does not migrate. Candidates with completed SkillSurvey reference checks may need to re-initiate the reference check process in Crelate or through the customer's preferred reference check vendor.

Hireology workflow templates defining the sequence of stages, automated actions, and approval gates are stored in Hireology's configuration layer and are not accessible via the public API. We do not migrate workflow templates as code. We deliver a written inventory of every active Hireology workflow with its trigger, stage sequence, automated actions, and hiring manager approval assignments, along with a recommendation for how to configure equivalent workflows in Crelate's pipeline and form builder. The customer's admin rebuilds them post-migration.