Migrate from Mobile Service App to Salesforce Sales Cloud

Source customers with company names map to Salesforce Account (Name) with Contact records underneath for individual contacts. Contacts without a company link attach to a default placeholder Account record. The primary contact per customer lands as the Account's primary Contact.

Service requests map directly to Salesforce Case records. Source status values map to Case Status pick-list (New, Working, On Hold, Resolved, Closed). Priority maps to Case Priority. The source customer ID links to Case ContactId via the previously migrated Contact.

Appointments with technician and customer links map to Salesforce Event records with WhoId (Contact) and WhatId (Case) populated. StartDateTime and EndDateTime map to Event StartDateTime / EndDateTime. If the destination uses Field Service Lightning, appointments map to ServiceAppointment with required Skills and Geolocation fields.

Technician profiles resolve by email match against existing Salesforce Users. If the technician does not have a Salesforce User, the record is flagged before migration — the team creates the User or assigns records to a fallback owner. Skills, certifications, and service territories map to custom fields on User or ServiceResource (FSL).

Source locations linked to customers map to Salesforce Account records with the Location record type, preserving address as the Account's billing address. Multiple service locations per customer become separate Account records linked by ParentId to the primary customer Account. Each location's geo-coordinates are stored in custom Latitude/Longitude fields for radius searches.

Photos and documents attached to service records are downloaded from source storage and re-uploaded as Salesforce Files. Files attach to the target record (Case or Event) via ContentDocumentLink. The 25MB per file Salesforce limit is enforced; larger files are flagged for manual review.

Source service type codes or categories map to either a custom pick-list field on Case (Service_Type__c) or a custom Salesforce object if the source has rich relationships. We evaluate the relationship cardinality before migration and recommend the simpler option. If a pick-list is chosen, we ensure all source values are added to the Salesforce pick-list and that field-level security allows appropriate user visibility.

Parts consumed during service visits map to a custom Parts_Used__c object linked to Case, or to OpportunityLineItem if the source includes billing integration. The migration plan evaluates whether source records include pricing data that should land in Salesforce CPQ. If CPQ is active, we map part numbers to Product2 SKUs and set unit prices accordingly.

Call logs, email records, and text notes attached to service requests map to Salesforce Tasks (Type = 'Call', 'Email'). Rich-text notes map to Salesforce Notes (not legacy Note object). Original timestamps, owners, and parent-record links are preserved. Call duration maps to Task.CallDurationInSeconds.

Latitude and longitude values from the source app are stored in Salesforce custom Geolocation fields (Latitude, Longitude) on Account or Case, or appended to the address compound field. Google Maps integration with Salesforce requires separate configuration post-migration. We also include a step to validate coordinate accuracy and to enable map-based visualizations in Lightning Experience.

Automated routing, status-change triggers, and notification rules in the source mobile app do not have a direct Salesforce equivalent and cannot be migrated. We export workflow definitions as a text reference document so your Salesforce admin can rebuild them in Flow or Process Builder.