Migrate from Gem to Crelate

Gem Candidates (internally Prospects) map directly to Crelate People. The mapping uses email address as the dedupe key with LinkedIn handle as a secondary match when email is absent. We preserve all standard candidate fields (name, email, phone, LinkedIn URL, location, current title, current company) and Gem-specific fields like work_history and education records. Gem's linked_in_handle deduplication logic triggers an update on existing Crelate People records rather than a duplicate insert when a match is found.

Gem Projects group candidates by sourcing initiative or requisition and map to Crelate Jobs. Each Gem Project becomes a Crelate Job with the project name as the Job title, project-level custom fields mapped to Job custom fields, and the project's candidate membership preserved as Job-Person associations. Teams that used Gem Projects to represent multiple open roles will see a 1:1 split (one Project becomes multiple Jobs) that we coordinate with the customer's recruiter during scoping.

Gem tracks which candidates belong to which Projects. We preserve this as a Job-Person association in Crelate, mapping the Gem candidate_id and project_id pair to the corresponding Crelate person_id and job_id. The association also carries any project-specific candidate status field from Gem.

Gem's custom fields on candidates (single-select, multi-select, freeform, date) map to Crelate Person custom fields. We note that Gem's single-select and multi-select fields are reportable and searchable, which is preserved in Crelate. Freeform text fields from Gem that were not searchable in Gem remain as freeform in Crelate but gain configurable visibility per layout in Crelate. We scope all candidate custom fields during discovery and confirm Crelate custom field types before migration.

Gem Project-level custom fields (team-wide fields applied to all candidates in a project) map to Crelate Job custom fields. Project-specific custom fields that Gem marks as non-reportable and non-searchable transfer as Job custom fields that Crelate's admin can configure for visibility and reporting post-migration.

Gem activity history (email interactions, InMail, SMS, calls, meetings, notes) attached to Candidates migrates to Crelate Activity records linked to the corresponding Person. We use Crelate's REST API to batch insert activities with parent-record resolution (person_id from the People mapping). Activity timestamps, disposition codes, and duration fields transfer where present. Some Gem engagement data locked to Gem's UI without API exposure may not be accessible; we flag inaccessible records during discovery.

Gem Positions synced from connected ATS systems map to Crelate Jobs. The Gem position record (job title, department, location, status) and its linked candidate associations migrate with the Job. Full ATS pipeline stage data from a connected ATS moves as Job stage history, though pipeline-to-Crelate-stage mapping requires confirmation from the customer's ATS admin during scoping.

Gem Owner records map to Crelate User accounts. We resolve by email match. Any Gem Owner without a matching Crelate User goes to a reconciliation queue for the customer's admin to provision the User before record import continues, since OwnerId is a required reference on most objects.

Gem Sequences are automated outreach cadences with A/B test configurations and multi-step messaging flows. Gem does not expose sequence definitions via API, so we cannot migrate them. We deliver a written inventory of every active Gem Sequence: step order, step type (email, InMail, SMS), delay between steps, A/B test variants, and enrollment criteria. The customer's Crelate admin rebuilds these as Crelate Workflows or as a documented manual setup guide. This is a high-severity scope item that must be agreed upon before migration begins.

Gem's BrightHire integration pulls AI-generated interview notes and scorecards into candidate records. Where the BrightHire integration is active, we map available interview notes and AI summaries to Crelate Person Notes or to a Crelate custom interview object if the customer's Crelate instance has one configured. BrightHire itself does not migrate; if BrightHire continues as a standalone tool post-migration, the BrightHire-Crelate integration must be reconfigured separately.

Gem call engagement records migrate to Crelate Activity records with ActivityType set to Call. Call duration, disposition, and recording URL fields transfer to Crelate custom Activity fields. Activity timestamp preserves the original Gem engagement date for timeline ordering.

Gem meeting engagements migrate to Crelate Activity records with ActivityType set to Event. Start time, end time, location, and attendee list transfer. Attendee associations map to Crelate Activity-Person links for each meeting attendee.