Migrate from Oracle Field Service Cloud to Salesforce Sales Cloud

Oracle FSL Activities are the primary service record — they contain the task description, time window, skill requirements, and resource assignment. In Salesforce, the Activity splits into Work Order (work definition: what needs to be done) and Service Appointment (scheduling: when and who). We map the Oracle Activity into both Salesforce objects with a shared key so the relationship is preserved.

Oracle FSL Resources represent technicians, vehicles, and crews. Each Resource has an email address used for identity resolution. We match Resource email to Salesforce User email, then create a ServiceResource record with the User as the RelatedRecordId. Unmatched Resources are flagged before migration so your team can decide whether to invite them as Salesforce users or assign their activities to a fallback owner.

Oracle FSL Locations store service addresses with contact name, phone, and address fields. These map directly to Salesforce Account records. The Account Name defaults to the location label from Oracle FSL if no formal company name exists. Multi-location accounts in Oracle FSL each become separate Account records with the same parent Account if a hierarchy is defined.

Oracle FSL Skills (e.g., HVAC-Certified, Electrical-Licensed) map to Salesforce FSL Skill records. The assignment of a Skill to a Resource in Oracle FSL becomes a SkillRequirement record linked to the ServiceResource in Salesforce. Skill names and proficiency levels are preserved in the Skill__c and SkillLevel fields on SkillRequirement.

Oracle FSL Assets are equipment or products installed at a Location — they track product model, serial number, install date, and warranty status. These map 1:1 to Salesforce Asset records. The Asset's AccountId is set by matching the Oracle FSL Location linked to this Asset with the migrated Account record.

Oracle FSL activity types are custom pick-list values configured in the admin console. Each activity type may carry its own set of custom properties. We map each Oracle activity type label to a corresponding Work Order Type value in Salesforce, creating the pick-list entries if they don't already exist. Custom properties per activity type migrate as custom fields scoped to the Work Order Type's record type.

Oracle FSL capacity quotas define how many appointments a resource can take per area, per category, per time interval (e.g., 5 jobs per morning in the 'North' area for 'Installation' category). Salesforce FSL uses Operating Hours linked to Service Territories and Capacity model records for this. We migrate the quota structure as custom fields on ServiceTerritory plus Operating Hours, flagging any interval-level granularity that cannot map natively to Salesforce's time-block capacity model.

Oracle FSL routing policies define optimization objectives, constraint weights, and vehicle routing rules. These are rule-based configurations with no direct Salesforce equivalent — Salesforce Scheduling Policies define service objectives and work rules but use a different optimization engine. We export the full Oracle FSL routing policy definitions as a reference document for your Salesforce admin to recreate in FSL Scheduling Policy.

Oracle FSL SLA definitions set response and resolution targets per customer tier or activity type. Salesforce uses Entitlement Processes with Milestones for SLA tracking. We map Oracle SLA bucket names to Salesforce Entitlement names and calculate Milestone target datetimes from the Oracle SLA response/resolution time values using the target Account's business hours.

Oracle FSL custom properties are per-activity-type data fields configured in the admin console. Each custom property has a data type (text, number, pick-list, date). We create a matching Salesforce custom field on Work Order with the appropriate type, scoped to the Work Order Type record type for which it was configured in Oracle FSL.

Oracle FSL tracks parts and inventory consumed per activity. Salesforce has no native inventory management at the FSL level. We migrate inventory items as Product2 records and create a custom WorkOrderInventory__c junction object to track which parts were consumed per Work Order. Your ERP integration handles real-time stock replenishment post-migration.

Oracle FSL activity attachments (photos, signatures, scanned documents) are re-uploaded to Salesforce as Salesforce Files linked to the corresponding Work Order or Service Appointment. File size limits of 25MB per file apply. Inline images embedded in activity notes are downloaded, re-hosted in Salesforce Files, and linked with the same parent reference.

Oracle FSL Organization Units define geographic or business-unit boundaries for routing. These map to Salesforce FSL Service Territories, which control which ServiceResources operate in which geographic area and what operating hours apply. We create a Service Territory per Oracle Organization Unit, preserving the name and linking it to the appropriate Operating Hours record.

Oracle FSL Crew records group multiple Resources for multi-technician dispatches. Salesforce FSL has a native ServiceCrew object. We map each Oracle FSL Crew to a Salesforce ServiceCrew, linking the member Resources via ServiceResource's CrewId lookup. Crew-level scheduling constraints (e.g., all members required vs. minimum crew size) are stored as custom fields.