Migrate from Hireology to Recruit CRM & ATS

Hireology Jobs (representing open positions at a specific location) map to Recruit CRM Job records. The Hireology job title, description, department, and location data transfer directly. The location reference from Hireology is preserved as a text field or mapped to a Recruit CRM office/location lookup if the destination has location records pre-created. Active and paused job statuses map to Recruit CRM's job_active flag. Closed or archived jobs migrate with status indicators for historical record completeness.

Hireology Candidates (applicant profiles potentially tied to multiple Jobs across locations) map to Recruit CRM Candidate records. Core profile fields (name, email, phone, resume, work history) migrate directly. Note that Hireology does not expose a unified candidate deduplication key via its public API, so we use email address as the primary dedupe anchor and flag any duplicate candidates for customer review before insert.

Hireology Applications link a Candidate to a specific Job at a specific location. In Recruit CRM, this junction is represented as a Candidate record associated with a Job via the internal application pipeline. We create the association by first inserting the Candidate, then inserting the Job association record that ties the candidate to the destination job with the appropriate status and application date from Hireology.

Hireology interview scorecards are sub-objects on the Application with per-question ratings and free-text reviewer comments. Recruit CRM supports a uniform scorecard schema. We map the reviewer name, overall rating, and per-question scores to Recruit CRM's scorecard fields. If Hireology rubrics vary by location or job type (which they frequently do), we normalize to the most complete rubric during migration and document any fields that cannot be mapped to Recruit CRM's uniform schema as part of the reconciliation report.

Hireology stores SkillSurvey reference check results as structured metadata (check type, pass/fail, date) linked to the Candidate or Application. The actual PDF report is not downloadable via Hireology's API. We migrate the structured result fields to custom fields on the Candidate record (check_type__c, check_result__c, check_date__c). Candidates who have completed background checks may need to re-initiate screening in Recruit CRM if the destination uses a different screening vendor. We flag this in the handoff documentation.

Hireology Locations represent individual franchise, retail, or branch sites with their own hiring managers and configurations. We map location records and reassociate them with the corresponding Job records in Recruit CRM. If the destination Recruit CRM account has office records pre-created by the customer, we match by location name and update the Job's location reference. Multi-location role hierarchies in Hireology are documented separately for admin rebuild since Recruit CRM's team and permission model differs.

Hireology allows custom fields on Jobs, Candidates, and Applications, but the public API does not expose a custom field registry enumerating all fields and their object associations. We discover the full custom field landscape during the discovery phase by sampling records across Jobs, Candidates, and Applications and comparing payloads against the standard schema. Each discovered custom field is then pre-created in Recruit CRM with the matching field type before migration begins. Fields that exist only on sampled records and cannot be verified against a schema definition are flagged in the reconciliation report.

Hireology Users (admins, hiring managers, recruiters with role-based permissions) map to Recruit CRM User records. We match by email address. Any Hireology user without a matching Recruit CRM account goes to a reconciliation queue for the customer's admin to provision before record import resumes, since OwnerId references on Candidate and Job records are required in Recruit CRM.

Hireology workflow templates defining stage sequences, automated actions, and approval gates are stored in the configuration layer and are not accessible via the public API. These do not migrate. We deliver a written inventory of every active Hireology workflow with its trigger, stage sequence, conditions, and automated actions, with a recommendation for how to rebuild each in Recruit CRM's Workflow Automation builder. The customer's admin handles the rebuild as a post-migration task.

Job board posting records and distribution history (which boards received the posting, when it was distributed) are not exported via Hireology's API. We migrate the job content itself but not the distribution history. Recruit CRM's job posting and VONQ/Indeed integrations serve as the replacement for job distribution, and the customer's admin configures these post-migration.