Migrate from Salesforce Field Service to Salesforce Sales Cloud

Salesforce Field Service Work Orders carry job status, priority, service territory, work type, and scheduled dates. Sales Cloud has no native Work Order object. We create a custom object with lookup to Account and, optionally, to the related Opportunity. The original Work Order number migrates as Service_History__c.Work_Order_Number__c for traceability. Active Work Orders can optionally link to Salesforce Cases if your team uses Case escalation.

Each Work Order Line Item represents a line on a service ticket: labor type, parts used, quantity, and unit price. We map these to a child custom object of Service_History__c. Parent Work Order resolved by WorkOrderNumber__c lookup. Line item sequence preserved in Line_Sequence__c. Parts migrated as text description plus custom price fields — Salesforce native Products and Pricebooks can be linked if your org uses them.

Service Appointments capture the scheduled and completed visit: assigned technician, arrival window, actual start/end times, and completion status. Completed appointments migrate as Salesforce Events with the original start/end timestamps preserved in custom datetime fields. Cancelled or no-show appointments migrate as Tasks with Type='Field Visit' and status='Not Started'. Parent ServiceAppointmentId stored for delta-run de-duplication.

Salesforce Field Service Skill records define a technician's ability (e.g., HVAC Level 2, Electrical License). Sales Cloud has no Skill object. We create a custom object linked to the Contact or User record representing the technician. Skill name maps to Certification_Name__c, proficiency level to Proficiency__c, and expiration date to Expiration_Date__c. Active skills on the source are flagged; expired certifications migrate with an Is_Expired__c checkbox set to true.

SkillRequirements define which skills a Work Order job requires (e.g., must be assigned to a technician with 'High Voltage' skill). We store these as a multi-select pick-list on the Service_History__c custom object or as a junction object between Service_History__c and Technician_Certification__c depending on your preferred lookup approach. Each required skill label maps to a matching Certification_Name__c value in the destination.

Operating Hours define business hours for a service territory or work type. Sales Cloud has no native OperatingHours object outside of Field Service. We map these to a custom object with TimeZone__c, Day_of_Week__c, Start_Time__c, and End_Time__c fields. Link to Service Territory by name lookup. These records are reference data — used to populate custom fields on Work Orders rather than driving a scheduling engine in Sales Cloud.

ServiceTerritory records define geographic zones for technician assignments and travel-time calculations. Sales Cloud has no equivalent. We create a custom object with Territory_Name__c, City__c, State__c, and Postal_Code__c fields. The parent OperatingHours linked by name. Address stored as a text field for reference. If your org uses Salesforce Maps, the territory boundary polygon is exported as GeoJSON and stored in a Long Text Area field — your admin can rebuild the shape in Maps Territory Management after migration.

WorkType defines the job category (e.g., Repair, Maintenance, Installation) and estimated duration per line item. Sales Cloud has no WorkType object. We create a custom pick-list field on Service_History__c with all WorkType label values migrated as pick-list options. Estimated duration maps to Estimated_Duration_Minutes__c. If your WorkType definitions include技能skill requirements, those route to the Job_Certification__c field per the SkillRequirement mapping.

Account records migrate directly 1:1 to Account. All standard fields (Name, AccountNumber, Industry, Type, BillingAddress, Phone) map by name. Multi-address support: Field Service may store multiple service locations per Account; we link secondary addresses as Account Address records or as custom address fields depending on your target org's configuration. Parent Account hierarchy maps via ParentId.

Contact records migrate directly to Contact. All standard fields map by name: FirstName, LastName, Email, Phone, MobilePhone, Title, Department. Contact ownership resolved by email match against destination Salesforce users. Contacts without a matching user flagged before migration; assigned to a designated fallback owner. Field Service-specific roles (Primary Technician, Customer Contact) preserved as a Contact_Role__c custom pick-list.

Salesforce users are not migrated — the destination org already has its own user base. We resolve the mapping between source FSL User IDs and destination User IDs by email address match. Source User records are stored as reference data in a migration audit table so you can trace which destination user each Work Order is assigned to. Unmatched users flagged with a User_Map_Status__c field in the audit log.

Assets (installed products tracked for service contracts) migrate 1:1 to Asset. Standard fields: Name, AccountId, ContactId, Product2Id, SerialNumber, Status, InstallDate, PurchaseDate. Asset Relationships for parent-child asset hierarchies map via ParentAssetId. Field Service Work Orders often link to Assets as the service target — the Service_History__c custom object carries an Asset_Lookup__c field linking back to the migrated Asset.

Entitlement records (service contract terms, SLAs, covered assets) migrate to the standard Entitlement object if your Sales Cloud org has Service Cloud licensed. Milestones and entitlement process steps are preserved as-is. If your destination org lacks Service Cloud licensing, entitlements are exported as custom fields on Service_History__c and linked to the covered Asset by name lookup.

Field Service managed package objects like Gantt_Palette__c, Map_Polygon__c, Optimization_Request__c, and SLR_Cache__c are internal FSL scheduling engine artifacts with no Sales Cloud equivalent. These records are exported as JSON reference files for documentation purposes only. Scheduling logic and territory geometry must be rebuilt manually in Salesforce Maps or Flow if required in the destination org.