Migrate from Connect Field Service to Microsoft Dynamics 365 Sales

Connect Field Service WorkOrders map to a combination of Dynamics 365 entities. For break/fix work orders we map to Incident (msdyn_workorder) with StatusCode reflecting the source WorkOrder.Status. For preventive maintenance or scheduled work orders we map to Agreement Booking Setup with recurring Agreement Booking Date Lines. The mapping choice is determined by WorkOrder.WorkType.SlaExitCriteria or a custom WorkOrder.Type field.

WorkOrderLineItem records map to Dynamics 365 msdyn_orderinvoicingproduct if the work order is linked to an Agreement and billable. If the line is a non-billable part used during a Case resolution, it maps to Case Resolution Product (incidentresolution) for the associated msdyn_workorder. Line item taxes from Salesforce's TaxLineItem require custom field mapping since Dynamics 365 handles tax via the finance side.

ServiceAppointment.StartTime and EndTime map directly to msdyn_bookableresourcebooking.StartTime and EndTime. The FSL AssignedResource record (junction between ServiceAppointment and ServiceResource) becomes the msdyn_resource lookup on the booking. BookingStatus maps from ServiceAppointment.Status via a value-mapping table since Salesforce FSL statuses (None, Scheduled, Travel, Onsite, Completed, Cannot Complete) differ from Dynamics 365 booking statuses (Pending, In Progress, Completed, Canceled).

The FSL Skill junction object (ServiceResource-to-Skill link with proficiency) maps to Dynamics 365 msdyn_resourcerequirement linked to the Bookable Resource. The Skill name becomes the msdyn_Skill.msdyn_SkillName lookup. Proficiency level from FSL_Skill.Proficiency maps to msdyn_RatingValue on the requirement. If no matching Dynamics 365 Skill exists, we create it as a custom Skill entity record before linking.

Salesforce FSL service territories map to Dynamics 365 msdyn_Territory records. Each territory gets its name, geographic boundary (if defined via FSL__Geolocation__c lat/long), and associated organizational unit. The territory linking to ServiceResource via FSL__Territory_Usage__c junction becomes msdyn_BookableResource.TerritoryIds in Dynamics 365. Multi-geography FSL orgs with overlapping territories require careful validation since Dynamics 365 territory scoping differs from FSL territory rules.

FSL scheduling policies (priority rules, travel time settings, booking window limits) have no direct Dynamics 365 equivalent that can be auto-created. We preserve the policy configuration as an exported JSON reference document for your Dynamics 365 admin to rebuild using Resource Scheduling Optimization admin settings. Priority weighting from Salesforce becomes scheduling goal configuration in RSO.

Salesforce Asset maps to Dynamics 365 msdyn_customerasset. The AccountId lookup maps to msdyn_AccountId. Asset.ParentAssetId (hierarchical parent-child) requires flattening because Dynamics 365's customer asset does not have a native parent link — we create a custom ParentAssetId__c text field and populate it with the parent's Salesforce ID for traceability. InstallDate maps to msdyn_InserviceDate, and Status maps to msdyn_AssetStatus via value mapping.

Work Type records map directly to Dynamics 365 msdyn_worktype. Name, FSL__Duration__c (estimated duration) maps to msdyn_EstimatedDuration, and FSL__Description__c maps to msdyn_Description. Billing type (Time and Materials vs Fixed Price) maps to msdyn_BillingType. If the source Work Type has FSL__ServiceReportTemplateId__c that generates PDF reports, those reports do not migrate — we export the template names for manual reconfiguration in Dynamics 365.

Salesforce ServiceResource (technicians and dispatchers) map to Dynamics 365 msdyn_bookableresource. The resource type (FSL__Resource_Type__c: Technician, Dispatcher, Others) determines msdyn_BookableResourceType (User, Contact, or Account). User-linked resources get their Dynamics 365 UserId via email matching. Resources without a matching D365 user are created as Contact-type Bookable Resources with a flag that they need a D365 license assigned before booking assignment.

Salesforce FSL geolocation fields on WorkOrder (FSL__Latitude__c, FSL__Longitude__c) do not have a native Dynamics 365 equivalent for work order address storage. We create custom latitude and longitude fields on msdyn_workorder and populate them from the source FSL geolocation values so dispatchers retain the service location coordinates on the work order in Dynamics 365.

Some FSL implementations use FSL__Incident__c as a parent record grouping multiple WorkOrders for a single customer issue. When present, we merge the incident's description, severity, and resolution into the primary msdyn_workorder record's description and msdyn_Resolution fields, preserving the incident ID in a custom Source_Incident_ID__c field for audit trail.

Salesforce file attachments on WorkOrder records migrate as SharePoint document library files attached to the corresponding msdyn_workorder. The original filename and content type are preserved. Files exceeding Dynamics 365's 32MB attachment limit are flagged for manual retrieval or chunked upload via Power Automate.