Migrate from Evatic to Salesforce Sales Cloud

Evatic Customers map directly to Salesforce Accounts. Customer name, address, primary contact information, and industry classification transfer as Account fields. Multi-site customers require decisions on whether to create one Account with multiple Locations or separate Accounts with a Parent Account relationship.

Evatic contact roles (primary technical contact, billing contact, escalation contact) map to Salesforce Contacts with a Role pick-list or custom Role__c field. Multiple contacts per customer are supported via standard Contact relationships to Account. The Role__c field can be a pick-list capturing titles such as Technical Manager, Billing Admin, or Escalation Lead, enabling targeted routing of Cases and communications.

Evatic Contracts contain SLA terms, response-time commitments, and billing frequency. These map to a combination of Salesforce Asset (for the equipment being serviced) and a custom Agreement__c object (for contract terms, SLA tier, and renewal date). Entitlement processes can be linked to the Asset.

Evatic Service Units with serial numbers, model descriptions, install dates, and location information map to Salesforce Assets. The Asset.AccountId lookup links each unit to the Customer-account. Parent-child unit hierarchies in Evatic map to Asset.ParentAssetId. If a unit has no parent, it is inserted as a top-level Asset, preserving its install location for reporting.

Evatic Work Orders map to Salesforce Cases with custom fields for technician assignment, parts used, and work-order-specific status values. Case.Origin maps from Evatic work-order type. Case.AccountId and Case.AssetId provide the customer and equipment context from the source. These lookups enable Case List views filtered by account or asset, supporting dispatch and reporting workflows.

Work order tasks and parts-usage line items need a custom child object or Case Comment entries in Salesforce. FlitStack creates a WorkOrderTask__c custom object with lookup to Case, task description, hours, and parts reference for detailed work-order auditing. Each WorkOrderTask__c record captures labor hours, parts consumed, and resolution notes, enabling granular service cost analysis.

Evatic technician records map to Salesforce Users by email match. If Evatic technicians are not Salesforce users, they migrate as Contacts on the relevant Account with a custom Role__c field identifying them as service personnel — Salesforce Cases can then reference them via custom lookup fields.

Evatic SLA terms (response time, resolution time, priority levels) have no direct Salesforce equivalent. FlitStack maps SLA terms to custom Number and Picklist fields on the custom Agreement__c object. Salesforce Entitlement processes can be configured to reference these fields for milestone tracking.

Evatic contract documents and service manuals attached to contracts or service units are downloaded and re-uploaded as Salesforce Files linked to the corresponding Account, Asset, or custom Agreement__c record. File size limits per Salesforce storage apply. All attachments retain original file names and metadata to preserve audit traceability.

Evatic billing history tied to contracts migrates as custom Invoice__c records linked to the Account and Agreement__c. Invoice line items map to custom InvoiceLine__c with product, quantity, and amount. Salesforce Orders can be used if the customer uses Salesforce CPQ for quote-to-cash.

Evatic custom fields on Customers, Contracts, or Service Units that have no Salesforce equivalent are created as custom fields on the mapped Salesforce object. Field types are matched: text to Text, pick-lists to Picklist, dates to Date, numbers to Number.

Evatic's dispatch rules, geographic routing, and technician scheduling logic are platform-specific constructs with no Salesforce equivalent. FlitStack preserves the technician-to-territory mappings as custom fields for reference, but scheduling automation must be rebuilt in Salesforce or a third-party scheduling tool. These custom fields capture territory IDs and routing priorities, aiding future automation design.