Migrate from Jarvis CRM to Salesforce Sales Cloud

Jarvis Contact records map to Salesforce Lead for unqualified prospect records and Salesforce Contact for qualified buyer records. We determine the split by evaluating the Contact's associated pipeline stage, lifecycle status (if present as a custom field), and relationship to any Jarvis Opportunity. Contacts with no Opportunity and no sales-qualified flag default to Salesforce Lead. Contacts linked to a closed-won or active Opportunity default to Salesforce Contact attached to a parent Account. We preserve the original Jarvis Contact ID as a custom field jarvis_contact_id__c on both Lead and Contact for audit reconciliation.

Jarvis Company records map directly to Salesforce Account. The Company name becomes Account Name; any industry classification field becomes Industry picklist; phone, website, and address fields map to standard Account fields. Account is created before Contact import so that the AccountId lookup relationship is satisfied at the moment of Contact insert. We resolve the Account ID from the jarvis_company_id__c reference during the Contact phase.

Jarvis Opportunity records map to Salesforce Opportunity with AccountId, OwnerId, and CloseDate resolved at migration time. The Jarvis deal value maps to Amount; deal stage maps to StageName with a mapping defined during scoping because Jarvis stage names are customer-specific. We configure Salesforce Record Types and Sales Processes to match the customer's Jarvis pipeline structure before migration begins.

Jarvis Project records map to a Salesforce custom Project__c object pre-created during schema design. Task structures and assignees map to ProjectTask__c records linked to Project__c. Gantt layout metadata (start dates, durations, milestones) migrates as custom fields on Project__c; raw task dependency chains are documented as a text export because Salesforce native Gantt requires PSA or an AppExchange project management tool. If the customer does not license a PSA, Projects migrate as Cases with a custom Record Type for project tracking.

Jarvis Time Entries (timecards and job-time records) map to a Salesforce custom Time_Entry__c object or to the standard Time Sheet object if the destination org includes Salesforce Health Cloud or a PSA. Billable and non-billable flags, hours, date, and linked Project or Contact references migrate as custom fields. Time_Entry_ID is preserved in jarvis_time_entry_id__c for audit trail. QuickBooks Online integration data (if live vendor billing exists in Jarvis) is flagged separately because it may belong in a financial system rather than Salesforce CRM.

Jarvis Vendor records map to Salesforce Account with a Vendor record type to distinguish them from customer Accounts. PO data and payment histories migrate as custom fields or related custom objects on the Account. QuickBooks Online vendor data referenced in the Jarvis integration is identified during scoping and either migrated to Salesforce or flagged for reconciliation in the customer's QuickBooks instance.

Jarvis Product and Service catalog records map to Salesforce Product2 with Standard Price Book entries created during import. Item names, prices, descriptions, and any custom product fields migrate to typed Salesforce fields. Product-to-Opportunity associations are preserved as OpportunityLineItem records with Pricebook2 and Product2 references resolved at migration time.

Jarvis task flows and activity records (follow-ups, assignments, internal notes) map to Salesforce Task with Status, Priority, ActivityDate, and Subject preserved. Owner assignment migrates by resolving the Jarvis user reference to a Salesforce OwnerId via the User mapping. Activity records linked to Contacts or Opportunities carry WhoId and WhatId references resolved after the parent Contact and Opportunity are imported.

Jarvis Campaign and contact group records map to Salesforce Campaign. Campaign metadata (name, type, start and end dates, budget) migrates to standard Campaign fields. Group membership lists migrate as Campaign Member records linked to the Campaign and the corresponding Leads or Contacts. Because Jarvis has no native marketing automation engine, campaign data is typically basic; we do not migrate engagement metrics as Activity records unless those metrics exist as explicit custom fields in the FileMaker schema.

Jarvis is built on FileMaker Pro and every deployment has custom fields that do not exist in a standard schema. We identify all custom properties during the mandatory schema audit, map each to a typed Salesforce custom field (Text, Number, Date, Picklist, Checkbox, or Lookup depending on the source field type), and pre-create the schema in Salesforce before data migration begins. Fields with no Salesforce equivalent are flagged in a written gap report for the customer's admin to decide on custom field creation or alternative handling.

File attachments stored within the FileMaker instance can be exported, but attachment storage format and location vary by deployment. We identify attachment storage paths during scoping, export files in their native format, and upload them to Salesforce as ContentVersion records linked to the parent record via ContentDocumentLink. Attachment migration is scoped separately from record migration because FileMaker attachment handling requires per-deployment investigation.

User records and owner assignments on Jarvis records are extracted from the FileMaker ACL and record-level ownership fields. We map Jarvis users to corresponding Salesforce Users by email match. Any Jarvis Owner without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes. OwnerId references on Opportunities, Projects, and Tasks cannot be resolved until the User mapping is complete.

Jarvis custom scripts written by The Scarpetta Group are not migrated as executable code into Salesforce. We document every active custom script identified in the FileMaker instance, describing its trigger, logic, and the records it affects. This script inventory is delivered as a written document for the customer's Salesforce admin or a Salesforce implementation partner to rebuild equivalent logic in Salesforce Flow, Apex, or a third-party automation tool.