Microsoft Dynamics 365 Field Service – An Approach to Data Migration of Work Orders from External Systems

If you are transitioning to Microsoft Dynamics 365 Field Service for the first time from a legacy system and have scheduled work orders and bookings that need to be migrated, there are a lot of considerations in regard to the generation of service tasks, billing products/services, durations, and pricelists.

In this article, I will detail one approach that aims to simplify the process and ensure that all the correct configurations are applied.

But first, let me explain the key components of the Work Order entity within Microsoft Dynamics 365.

1. Account (in this case relabeled to Household in Microsoft Cloud for Healthcare solution) – This is the account in which the service will be delivered. The Account address is important, as address information will flow through to the Work Order and is geocoded to a location for the purposes of scheduling and calculation of travel time.
2. Billing Account – This is the billing account for this service, in many cases the billing account (in particularly the email or postal address) will be different to the delivery of services account. This information is important for the eventual generation of invoices for a completed work order.
3. Price List – These are the prices that will be applied for given services/products for this specific account/work order. It is important to ensure that all products to be used in this work order have a corresponding Price List Item – the Price List item is the intersection between the Price List and the Product/Service, and it dictates the pricing/rate as well as any tax to be applied. It should be noted that Field Service also has an extended pricing model, which, on top of the normal Price List Item, a Field Service Price List Item may be applied. A Field Service Price List Item may contain configurations for Flat Fee, Rounding Policies, Minimum Charge, and Minimum Duration. I won’t be covering this aspect specifically in this article, but it is important to note that Field Service Price List Items allow you to extend your pricing model for more advanced pricing scenarios.
4. Primary Incident Type – The incident type informs the Field Service system as to the requirements of this work order. Within the Incident Type configuration record you can apply common tasks, products, services, along with characteristics of this Work Order. This is important for the next point 5).
5. Product, Service, Service Tasks (and Characteristics) – When an Incident Type is set to a work order, a background Field Service workflow will execute that copies across all the Service Tasks, Products, Services, and Characteristics related to the Incident Type across to the Work Order. This helps with standardising work for a given Incident Type.

With the above explanation out of the way, let’s take a look a fictitious appointment in an external system and look at how we may migrate this record over to Microsoft Field Service.

Step 1 – Create your Incident Types, Service Tasks, Products/Services, Characteristics

The first thing to tackle is the creation of an Incident Type. For the above appointment types, it would be wise to create a corresponding Incident Type such as Follow Up Assessment, Physio Appointment, or Optometry Appointment. Each of these Incident Types should include all required Service Tasks (e.g. a checklist for assessment), products (e.g. a pair of prescription glasses), services (e.g. service charge for an assessment). The Service Tasks, Products and Services should already exist within the system – that would necessitate creating this list ahead of your creation of an Incident Type.

Step 2 – Import your Customers as Accounts, Verify their Billing Details, Price List, and Address

With the Incident Type now established, next we will need to verify the Customer’s address and ensure that it has the correct pricing. As discussed earlier, this information is important to scheduling (for on-site appointments). So therefore the Customer table should be migrated to the Field Service solution (as Accounts) with the correct address, billing account, and pricelist.

Step 3 – Convert your Appointment Dates to GMT+0

As Field Service is designed to work across different geographies, all your appointments must be firstly converted to Greenwich Mean Time (GMT) prior to importing to the Work Order table. This will allow scheduling to be performed by your resources who operate in different jurisdictions.

Step 4 – Import Work Orders

Next with the data sanitised, proceed with your import (which can be achieved through a number of mechanisms not covered here, e.g. direct CSV import, SSIS package, direct SQL queries).

In this approach, we will be leaving the Field Service plugins enabled to allow for the creation of all Service Tasks, Products/Services, Characteristics to be associated with the work order (this occurs when an Incident Type is applied to a Work Order, and subsequently creates a Work Order Incident record). If your approach is run with plugins disabled, this information must be manually created (for reference these tables are as follows: Work Order Service Tasks, Work Order Products, Work Order Services, Work Order Characteristics, Work Order Incident).

As mentioned earlier, all times must be entered in GMT time to enable scheduling, so if transformation is required in your data migration package, ensure this has been done prior to import; otherwise, data will be imported in the user’s local time.