Migrate from In-recruiting to Crelate

In-recruiting Candidate records map directly to Crelate People records. The In-recruiting candidate identifier is preserved in a custom field ir_candidate_id__c for cross-system reference. First name, last name, email, phone, and address fields map with direct field correspondence. Any In-recruiting candidate source field maps to Crelate's candidate_type and additionally to a custom field ir_original_source__c to preserve attribution. Candidate tags from In-recruiting map to Crelate's Tags using the Default tag category.

In-recruiting client or company records attached to a Candidate map to Crelate Organization. The Organization Name maps from In-recruiting's company name field. Industry, website, and address fields transfer directly where populated. If In-recruiting stores client contacts separately from candidate contacts, the client contact maps to a People record with a Client relationship type linked to the Organization via Crelate's contact-account lookup pattern.

In-recruiting Job records map to Crelate Job. The job name, description, employment type, and location fields transfer directly. Job status (Active, Paused, Closed) maps to Crelate's job status field. We flag any In-recruiting job that has a live posting at migration time and sequence it for the final migration pass to avoid disrupting ongoing applications. Owner assignment maps via email lookup against Crelate Users.

In-recruiting Application records link a Candidate to a Job and carry the application date, status, and current pipeline stage. We map Application directly to Crelate Application, preserving the application timestamp and status. The In-recruiting application ID is stored in a custom field ir_application_id__c. If the In-recruiting application record carries custom application-stage notes or ratings, these map to Crelate Application custom fields created during the schema design phase.

In-recruiting pipeline stages are configurable per job. We create matching pipeline stages in Crelate before migration, using the stage names and ordering from In-recruiting. Each In-recruiting stage transition timestamp is preserved as a custom activity or note entry in Crelate attached to the Application record, since Crelate's stage history field model differs. The mapping is validated during the staging pass before production import.

In-recruiting Interview records map to Crelate Interview with interviewer name, scheduled date and time, interview type, and outcome fields preserved. Interviewer contact details are resolved against Crelate's People table via email lookup. If In-recruiting stores interview scorecards or feedback as structured fields, these map to custom Interview fields we provision in Crelate before migration. The interview status (scheduled, completed, cancelled) transfers directly.

In-recruiting Notes attached to Candidate, Job, or Application map to Crelate Note records linked via ContentDocumentLink to the parent People, Organization, or Job record. Note body transfers as rich text. Note creation timestamp and the author (owner) resolve against Crelate's User table by email. Notes that reference other In-recruiting records (e.g., referencing a Job or Application) are preserved as plain-text cross-references in the note body and do not create live Crelate lookups.

In-recruiting candidate attachments — primarily resume files in PDF, DOC, or DOCX format — migrate as Crelate ContentDocument records linked via ContentDocumentLink to the associated People record. File names and MIME types are preserved. Files larger than 25 MB are flagged for the customer to review before migration because Crelate's API handles attachments in batch with size constraints.

In-recruiting User accounts resolve against Crelate Users by matching email address. We perform this resolution before any record import so that OwnerId references on Jobs, Applications, and Interviews are satisfied at insert time. In-recruiting Users without a matching Crelate User are held in a reconciliation queue, and the customer's admin provisions the Crelate User account before the production migration pass. Active versus inactive status carries over based on In-recruiting's user active flag.

In-recruiting custom fields that are not standard-field equivalents require pre-creation in Crelate before migration data is written. We review the In-recruiting export during discovery, map each custom field to a Crelate custom field of the appropriate type (text, number, date, picklist, checkbox), and deploy the Crelate custom field schema into the target account before any test migration runs. Crelate's field-mapping feature from custom forms to parent records is noted as a secondary mapping path but is not used during bulk migration.

In-recruiting job board distribution records indicate where a Job was posted externally. These are not standard Crelate records but map to Crelate's active job board integrations. We document which job boards were connected for each In-recruiting Job and provide the customer with a list of Crelate-native job board integrations (Indeed, ZipRecruiter, Monster, CareerBuilder, Glassdoor, Dice, and others) to reconnect during post-migration setup.

If In-recruiting stores candidate ratings or scores as structured fields on the Candidate record, we map these to Crelate custom number fields on the People record. The rating scale is preserved (e.g., a 1-5 scale from In-recruiting transfers as a custom Crelate field ir_rating__c with the same scale). We validate scale consistency during the staging pass.

In-recruiting activity logs associated with a Candidate — including calls, emails, and internal communications — map to Crelate Activity records (as Note or Task entries) attached to the corresponding People record. Activity timestamps are preserved as ActivityDate. Call duration and disposition, where stored in In-recruiting, transfer to custom Activity fields. Email body content migrates as a Note linked to the People record.