Migrate your Dynamics 365 Field Service data

Work Orders are the central entity in Field Service, holding status, priority, service account, incident type, and required skills. The schema is stable and well-documented in the Dataverse entity reference. We migrate Work Orders 1:1 and preserve the full audit trail where the source exposes created/modified timestamps.

Bookable Resources represent technicians, vehicles, and equipment with their skills, territories, and calendar-based availability. We map these to the destination's resource entity, preserving skill tags and resource type (user vs. contact vs. equipment) to maintain scheduling continuity.

Resource Bookings link Work Orders to Bookable Resources with time windows, travel time, and booking status. We migrate these as a joined entity pair (header + line-equivalent) and flag any orphaned bookings that reference missing Work Orders or Resources in the destination.

Accounts and Contacts are standard Dataverse CRM entities. We migrate them with their full address hierarchies and relationship mappings to Work Orders. Any custom address format fields require field-level mapping to the destination's address schema.

Cases represent customer issues and are often linked to Work Orders or Assets. Field Service may use the parent Case entity or a custom incident type structure. We map the case hierarchy and thread entries but need to confirm whether the destination uses the native Case entity or a project-centric variant.

Customer Assets track equipment installed at service locations with serial numbers, warranty dates, and parent-child hierarchies. We migrate asset trees but must map the destination's asset schema—some platforms use a flat structure where Field Service uses a hierarchical one, requiring flattening during import.

Products define the service catalog with pricing, units, and product type (inventory vs. non-inventory vs. service). Inventory tracking with warehouse bins requires mapping to the destination's inventory management module, which may not exist in non-ERP destinations.

Service Level Agreements define response and resolution time commitments linked to Work Order templates. SLA terms translate to field-level values in the destination, but cascading SLA rules (e.g., pause conditions, breached escalation paths) require custom field mapping.

Schedule Board views, filters, and color-coding rules are stored as user-specific UI preferences in Dataverse. These are not exported as portable artifacts. We do not migrate schedule board configurations directly; we document them as setup tasks for the destination environment.

Automated workflows built in Power Automate that reference Field Service entities are tied to the source tenant's connector registrations. These flows cannot be exported and re-imported as functional pipelines without manual re-authentication and trigger reconfiguration in the destination org.

Inspection forms used in Field Service mobile are stored as custom entities or as part of the Field Service Inspections add-in. The schema varies depending on whether the source uses the native inspections framework or a custom Power Apps canvas app form.

IoT alerts trigger Work Order creation via Azure IoT Hub integration. Alert rules, thresholds, and automation paths are configured in Connected Field Service and stored across Dataverse and Azure resources. We migrate the alert-to-Work Order mapping logic but cannot transfer the Azure IoT Hub connection itself.

Technicians log time against Work Orders using the Time Entries entity, which may include billable vs. non-billable flags and project code associations. We map time entry records but must confirm whether the destination charges time against Projects, Projects + Tasks, or a flat Work Order.

Work Order attachments (photos, signatures, documents) are stored as Dataverse annotations (notes) or SharePoint document locations. We migrate annotation text and inline image references; SharePoint-hosted files require separate file migration with URL remapping.