Work Orders – I

This post is a part of a “Field Service for Citizen Developers” series. Click here to see other posts.

Work Order is the “work” itself – which is scheduled and then actioned by the field service staff. Some examples are:

1. For a furniture company, a work order is to deliver and install furniture at a customer locationFor a furniture company, a work order is to deliver and install furniture at a customer location
2. In a cleaning business, a work order is to visit a customer and do the cleaning job
3. For service and warranty department of an electronics company, a work order is to visit a customer, investigate why an installed device is not working, and then fix or replace
4. For a construction company, a sample work is one of the tasks from the project plan

The objective of the business is to schedule and complete “Work Orders” as efficiently as possible and with the maximum satisfaction of the customers.

For understanding this fundamental part of the app, we will look into following areas:

1. The composition of a Work Order? (fields, relationships, key pre-requisites etc.)
2. How Work Orders are created?
3. Status life cycle of Work Order from creation to completion

In this part, we will focus on the first question: what constitutes a Work Order in Dynamics 365 Field Service app.

The composition of a Work Order in Dynamics 365 Field Service

A typical way to understand design of any record type (entity) in the app is to review data model, relationships and business rules. For this particular entity, however, we will take a different route. We will first look at an example from real world, then map that example to entities, fields and relationships in Dynamics 365 field service and then finally look at the structure/data model on Microsoft Docs website.

Let’s imagine you work for a medical devices manufacturer company and you are responsible for keeping those devices up and running in all your customer sites (hospitals and surgeries). On a typical workday, you’d have your field technicians visit customer sites to do preventative maintenance, install new devices and address customer complaints by fixing/upgrading or replacing devices. Here is an example work order that you would assign to your field technicians:

The example is pretty much self explanatory, basically work involves two jobs: installing a new X-ray machine and fixing a CT scan machine. It is being planned for City Hospital and two field technicians (James and Sarah) will be scheduled to do the work. Now what I am going to do next is to use the same example but paraphrase with the terminology of Dynamics 365 Field Service app:

Legend: Blue are fields in Work Order entity while Black are related records (child entities) of a typical work order.

The top part is the Work Order record which contains key information about the work: work order number (a unique reference), who is the customer, who this work will be billed to, address of the work, priority etc.

Then each work order may have one or more jobs under it. These jobs map to an entity called Work Order Incidents. Since these jobs are usually standardised, there is an entity called Incident Type (read it as ‘Work Templates’) which is used to keep checklist, product used, duration etc. as a template for these jobs. In our example, two jobs (or Work Order Incidents) are mentioned, each having its own checklist (Service Tasks) and a linked Product and an Asset.

From functional perspective, following map links ‘functional purpose’ with the fields or entities in Dynamics 365 Field Service:

Note: I am deliberately leaving the part on how the work is scheduled for James and Sarah in above example for the later post on Booking (published now).

Hope this helps in mapping your field service business requirements to the structure of ‘work’ definition in Dynamics 365 Field Service. Next, before concluding this post, we will look at key fields of Work Order and its child entities:

• Service Account and Billing Account: As you’d guess, both of these fields let you select one of the Accounts in the system. Why two fields instead of just one customer field like case? Well, if customer is paying for the service herself, then both Service Account and Billing Account fields would be same, but if you’re working for a customer but will be paid by customer’s employer, or if you’re working for a regional office but will be paid by corporate head office, then you would select appropriate account records in Service Account (where and for whom work is done) and Billing Account (who is paying for the service) fields

• Location: Location is basically a table on Work Order main form which contains address fields and two extra fields for geocoding: latitude and longitude. If Service Account has address and that address is geocoded, then these fields get auto populated. In any case, the location and lat/long can be edited on Work Order on the map itself. The benefit of having geocoded address is to schedule work per proximity (schedule resources to work that are physically close to the customer site) and for field staff to navigate to the customer site using driving directions

• Customer Asset: Customer asset is a lookup to Customer Asset entity

• Work Order Products: this is a child entity which makes it possible to associate one or more products to a work order. These could be products to be consumed to do the work or the products that are installed as part of work order to the customer site (which means, products then becomes customer assets)

• Service Tasks: Service tasks are like list of to-dos for getting the work order completed. They have a ‘%age completion’ field which can be used to record exact progress of the task, though in most implementations this is used as boolean – 0% (not started) to 100% (completed)

• In addition to above, other key fields on work order are Priority, Territory, fields related to scheduling e.g. preferred start time, field related to origin of work order, e.g. case etc.

Lastly, here is a reference to the data model and structure of the work order from Microsoft Docs.

Hope this was useful, please feel free to share your feedback on twitter or share your comments.