Migrate from Service to Salesforce Service Cloud

The core ticket object maps directly to Salesforce Case. The CaseNumber in Salesforce is auto-generated; the original Service ticket ID is stored as Source_System_Ticket_ID__c for traceability. Priority, status, and origin pick-list values are mapped value-by-value against the target org's active Case Status and Case Origin pick-lists.

Service customer records map to Salesforce Contact. Salesforce requires a Contact to have an AccountId — contacts without a primary company are attached to a default 'Unassigned Account' or resolved by domain-matching to an existing Account. Email is the deduplication key.

Service company or organization records map to Salesforce Account. Parent-company hierarchies in Service map to Account.ParentId, preserving organizational structures across both platforms. Annual revenue, employee count, and standard address fields map directly. Industry pick-list values require value-mapping against Salesforce's standard Industry pick-list; any Service-specific industry values must be added to the target org's pick-list before migration.

Service agent IDs are resolved by email match against Salesforce User records. OwnerId on Case accepts both UserId (individual owner) and QueueId (team queue). Unmatched agents are flagged before migration and assigned to a fallback owner or pre-created as Salesforce Users. Queues must exist in Salesforce before they can receive Case.OwnerId assignments.

Service comment entries become Salesforce EmailMessage records for inbound/outbound messages or CaseComment records for internal notes. Original timestamp, body, and author are preserved. HTML-formatted comments are sanitized to Salesforce's rich-text EmailMessage.Body field. Each message gets its own record so thread chronology is intact.

Service's SLA duration fields (time-to-first-response, resolution-time) have no direct Salesforce equivalent — they map to Entitlement and MilestoneType objects. Each Entitlement record links to a Contract and defines milestone types with business-hours calendars. FlitStack creates Entitlement records with milestone history preserved as custom datetime fields (Original_FirstResponse__c, Original_Resolution__c) for reporting continuity.

Service product records map to Salesforce Product2. If Service links products to tickets as installed assets, those become Salesforce Asset records linked to the Account and Product2. Serial number, status, and install date fields map directly. Asset must exist before the Case can reference it via AssetId.

Service custom fields are created as Salesforce custom fields on the corresponding object. Salesforce API names get the __c suffix. Pick-list custom fields require value-by-value mapping against the target pick-list. Multi-select pick-lists in Service map to Salesforce multi-select pick-lists. If the target org does not yet have the custom field, FlitStack creates it via API before writing data.

Service file attachments are downloaded and re-uploaded as Salesforce Files (ContentVersion / ContentDocument). Each file is linked to the Case via ContentDocumentLink. File size limit in Salesforce is 25MB per file; larger files are flagged for manual handling. Inline images embedded in comments are extracted and rehosted as Salesforce Files.

Service tags or category labels used for ticket classification have no native Salesforce equivalent beyond standard Case Type and Reason pick-lists. We migrate them as a custom multi-select pick-list (Ticket_Categories__c) for reference and reporting. Your admin can expand this into a formal taxonomy using Case Type hierarchy.

Service workflows and auto-assignment rules are business logic that live in the source platform's execution engine. They are not exportable as data. FlitStack extracts rule definitions as JSON exports and documents the rebuild steps in Flow Builder and Omni-Channel Routing so your admin can reconstruct the logic in Salesforce.

Service SLA definitions map to Salesforce BusinessHours records and Entitlement Processes. The Entitlement Process defines which milestones apply to which cases based on Entitlement name or Account. Business hours (timezone, working-hours schedule) must exist in Salesforce before the Entitlement Process can reference them.

Service macros and email templates are not data objects and cannot be migrated as records. FlitStack exports macro body text and template content as structured JSON. Salesforce Quick Actions, Flow email actions, or Salesforce Knowledge article templates are the destination equivalents — rebuilding them is a post-migration step.

Report and dashboard definitions live in the application layer, not in data. Salesforce reports reference object IDs that change post-migration. FlitStack documents the source report metrics and filter logic so your admin can rebuild them in Salesforce Report Builder pointing at the migrated Case object.

If Service tracks billable time entries per ticket, those map to a custom field (Billable_Hours__c) on Case or a custom TimeEntry__c object linked via lookup. Whether billable time is a single aggregate field or a line-item table depends on your reporting needs — FlitStack surfaces this choice in the mapping plan.