Migrate from Jarvi to Crelate

Jarvi Candidates map directly to Crelate's Person record with candidate type. Standard fields (name, email, phone, status, current stage) migrate cleanly. We resolve the unpaginated profiles endpoint by streaming the full candidate response in chunks on our end, preventing timeout during extraction for large candidate pools. Jarvi AI-generated candidate summaries land as custom text fields on the Crelate Person record; we flag any orphaned AI data if the destination custom field schema is incomplete.

Jarvi CRM-layer Contacts (client and prospect records) map to Crelate Person with contact type designation. Contact records include company association, lifecycle stage, and multichannel communication history. We map the Jarvi contact_company_id to the Crelate Company lookup by matching company name or domain during the transform phase.

Jarvi Jobs represent both job requisitions and active placements depending on how the agency uses the object. During scoping we determine whether each Jarvi Job is a mandate (Job Order in Crelate) or a filled placement (Placement in Crelate). The split is resolved based on job status, associated candidate submissions, and the agency's stated workflow. Each Job preserves its linked pipeline stages and associated candidate associations.

Jarvi allows custom pipeline stage definitions per job or per CRM deal. Stage names, ordering, and win/loss states vary by organization. We extract the stage schema alongside each record, map the stage names to Crelate Workflow stage values, and configure the Crelate Workflow pipeline before candidate and job data loads. Stage probabilities migrate where present.

All Jarvi outreach actions (emails, LinkedIn messages, calls, meetings) stored as Activity records linked to a Contact or Candidate migrate to Crelate Activity records. We preserve the full activity timeline including timestamps, channel attribution, and message content. Thread structure from Jarvi's unified conversation view maps to Crelate's Activity feed; multi-channel attribution (LinkedIn, WhatsApp, Telegram) is stored as custom fields on the Activity record in Crelate if no native multi-channel thread model exists.

Jarvi Company records (firmographic data, industry, size, revenue tier) map to Crelate Company. Multi-contact and multi-job associations transfer as Crelate Relationship records or linked Person records. We use company name as the dedupe key during import to prevent duplication where a Company record already exists in Crelate.

Jarvi exposes a UUID-based Custom Fields API for Candidates and Contacts supporting text, number, date, and dropdown types. We retrieve the custom field schema before migration and map values to Crelate Core Record custom fields created via Settings. Crelate's Logical Name (API field name) is assigned during schema creation; the display name maps from Jarvi's field label. Dropdown values migrate as Crelate picklist options with exact value matching.

Jarvi resumes, cover letters, and uploaded documents attach to Candidate profiles. The platform stores file metadata and a reference URL. We export attachments alongside candidate records and upload them to Crelate's document management area, attaching each file to the corresponding Person record. File hosting parity is not guaranteed; the customer should verify attachment access post-migration.

Jarvi threads messages across LinkedIn InMail, email, WhatsApp, Telegram, and standard SMS into a unified conversation view per Contact or Candidate. Crelate does not replicate this unified thread model natively. Individual message events migrate as separate Activity records with channel attribution preserved; we do not reconstruct the conversational thread UI. Channel metadata (LinkedIn vs WhatsApp vs Telegram) is preserved as a custom field on each Activity record.

Jarvi Owners map to Crelate Users. We resolve by email match during the transform phase. Any Jarvi Owner without a matching Crelate User is placed in a reconciliation queue for the customer's admin to provision before record import resumes, because OwnerId references are required on most standard object imports.

Jarvi's AI agent generates candidate summaries and evaluations stored as linked data points rather than standalone objects. These export as custom text fields on the candidate record. We migrate them as Crelate custom text fields on the Person record. If the destination Crelate account lacks a corresponding custom field, we flag the orphaned AI data in the migration report and recommend regenerating summaries using Crelate's own AI tools post-migration.

Jarvi tags stored as multi-checkbox properties migrate to Crelate custom fields with multi-select picklist type. The customer chooses during scoping whether tags become custom fields on Person records or are handled via Crelate's tagging mechanism if available. Tag taxonomy is preserved during transform.