Tag: Work Orders

Posted on

Work Order Resolutions

One of the standard requirements for Field Technicians is to record ‘what’ happened after they finished the work. This ‘what’ relates to two things:

  1. Log of the work (fixing, maintenance, installation, work around etc.) performed, and more importantly;
  2. Record any future implications of the work performed
Photo by Markus Spiske on Pexels.com

This requirement was usually met using ‘Work Order Summary’ field on Work Order, Status/Sub-status or a combination of these options but now an introduction of ‘Work Order Resolution’ opened new avenues. In this post today, I am going to explore this feature.

What is Work Order Resolution

Resolutions is a new table in Dynamics 365 Field Service. It links with Work Order and also can be related to Incident Types. You can find it under Settings -> Resolutions.

How to Setup

Click ‘New’ to create a new record. I am calling my first resolution record as ‘Standard maintenance resolved the issue’.

Notice a second tab called ‘Incident Type Resolutions’? This is an excellent but an optional feature where you can link certain resolutions with specific incident types. For instance, you can only ‘replace batteries’ (resolution) of ‘electric car maintenance’ (incident type), therefore it will make sense to relate them. In real life, you may have some ‘Incident Type’-specific resolutions while others could be generic.

In this particular example, I am linking my resolution to a specific incident type. Go to the next tab and click New to create a new record, select incident type and click Save:

You can similarly link this same resolution with multiple incident types:

Next, lets create one more resolution record:

How to Use

Lets create a Work Order now:

Go to resolutions. A resolution record can be added both from web (by Dispatcher, most likely) or Field Technicians on mobile. If any Incident Type specific resolutions are defined, then you will only see those records. Alternatively, you can create a new Resolution record too:

Once resolution is selected, you can also see that under Related Records:

Last but not the least, resolution form also contains a ‘Customer Asset’ field while enables dispatcher or Field Technician to select any asset.

Conclusion & Further Reading

I think the design of Work Order Resolution is elegant as it allows you to be both very generic (resolution not defined against any incident type) and very specific (resolution record per incident type and also per asset). The reality could be on any ends or in the middle of this spectrum – based on business requirements.

For further reading, have a look at Microsoft Docs.

Thanks for reading!

Feel free to share your feedback, I’d love to hear your thoughts 😊

Posted on

How to create a follow-up Work Order?

This is a quick “How-To” article on an oft-used scenario in field service organisations: how to create a follow-up work order for future work?

The ‘Why’

This may happen for several reasons, such as:

  1. Technician does a quick workaround fix today and is wanting to book a future work for parts replacement, 
  2. field service staff installs a new part and wants to set a reminder to check the status in a month time 

How to achieve this? An obvious solution is to set up a ‘Follow-up Work Order’ which can be then scheduled by Dispatchers. Is this feature supported in Dynamics 365 Field Service? The answer is, as you may have guessed, yes đŸ˜Š – as an out of the box feature. Let’s have a look at how it works.

The ‘How’

Create a work order in Dynamics 365 Field Service and book a resource to create a booking. Next log into Dynamics 365 Field Service app, click on Bookings to view bookings. Click on a booking to open a record.

Next, click on ellipses on the bottom to see all sub-menu items and click on Follow-up

This will open a ‘new’ Work Order screen

Notice that Service Accounts and Billing Account are pre-populated.

That’s it! Quick and easy with a minimum number of clicks for field resources to create a new Work Order record.

Caveat: this function doesn’t auto-link the two work orders or set one parent of another. However, this behavior can be easily set up using Power Automate flows [or using client site script – but I won’t recommend this approach].

Thanks for reading!

Feel free to share your feedback, I’d love to hear your thoughts 😊

Posted on

Subgrids ➡ Dialogs on Work Order

Can UX be quantified? I think one way to assess usability is to count the number of clicks required to complete a functional activity in the system. In the context of Dynamics 365 Field Service, for example, this could be creating a Work Order, scheduling, setting up a servicing schedule for assets etc. So then the question is – how good is the usability index (if we shall call it) of these Dynamics 365 Field Service?

Photo by Markus Winkler on Pexels.com

Not much, right? Requires too many clicks!

The user experience of Dynamics 365 is based on the main entity form and then navigating to ‘related entities’ through subgrids in same or different tabs. Owing to the complexity of the service business, the data model of Dynamics 365 Field Service has a lot of relationships between entities which invariably translates into heaps of clicks when you are working on these records: Work Orders, Agreements, Purchase Orders etc. So what is the solution?

Introducing the new ‘subgrids as dialog’ feature…

Arriving in the bandwagon of 2020 Release Wave 2 is this new feature which basically makes related entity forms on a Work Order to open like dialog. Here is my little video of test drive of the features (it is in early release view at the moment). The key outcome of this feature is the ability to complete an entire functional activity (e.g. to create a work order and related products, services etc.) from one screen only.

Note: This is currently supported on below entities only:

  1. Work order product
  2. Work order service
  3. Work order service task
  4. Work order incident
  5. Bookable resource booking
  6. Time entry

End result:

Lesser clicks, shorter data entry time and increased productivity = Happy Customer đŸ‘©â€đŸ’»

Thanks for reading!

I’d love to hear your thoughts 🙂

Posted on

Making Field Service Smarter using AI Builder

Quality audit is part of a work management life cycle in most Field Service organizations. To ensure customers are satisfied, equipment is up and running, and there are no SLA breaches, a quality audit is conducted in all or statistically sampled work orders. This often means creating another booking, or a task, or creating a follow-up work order for quality check and of course additional resource requirements – but is there a smarter solution possible in Dynamics 365 Field Service? This post explores the possibility of using AI Builder.

The Challenge:

In our Contoso field service organization, this is how the work happens:

  1. Field Technicians are booked to conduct the work
  2. Field Technicians complete the work, take a picture and uploads in the app
  3. Supervisors take a look at the picture, make a conscious call to either approve or visit a site to confirm work is properly completed
  4. Work Order is completed after the quality check has passed

For the point (3) above, we’ll use AI Builder’s object detection model to train it on pictures of quality vs faulty work, and then once a model is trained, hook it up with Field Service to check the quality of work and then change the status of Work Order automatically. This is how the process will look like:

The Setup:

We’ll need the following Power Platform products:

  1. Dynamics 365 Field Service
  2. AI Builder
  3. Power Automate Flow

All of the above can be setup as a trial for this post.

As for the images of quality vs faulty work, I’ve tapped into vast datasets available on Kaggle and found this one with the images of Lego bricks. For our experiment today, we’ll use 20 images each of 4×4 vs 1×2 bricks to differentiate quality vs fault work:

Faulty Work:

Quality Work:

The Play:

Following are three steps to run this play:

  1. Dynamics 365 Setup
  2. Build a model in AI Builder
  3. Create a flow to call AI Builder model with Dynamics 365

1. Dynamics 365 Setup:

Create a new field on Work Order entity:

Name: Completed Work

Type: File

….and drop it on a form.

Field Technicians upload the image of completed work in this field. We’ll use Power Automate to call AI Builder model on this field’s content.

2. Build a model in AI Builder

Create a new AI Builder model of type Object Detection and name it as ‘Quality Check’. Click Next..

Select ‘Common Object’ and click Next..

Add two ‘Object names’ as Quality and Faulty work. Click Next.

Click on Add images and upload all 40 images..

Click on Add images and upload all 40 images..

Click on Tag images and start tagging images one by one as Quality


and Faulty work:

Let’s have a look at the Summary and then click on Train. It will take few minutes.

Once trained, run a few Quick Test. Seems to be working for me 🙂.

Quick Test 1:

Quick Test 2:

Create a flow to call AI Builder model with Dynamics 365

Let’s go to Power Automate flow and click New. We will use ‘Common Data Service (current environment)’ trigger and have the following actions:

Trigger: When a record is created, updated or deleted on Work Order

Steps:

  1. Get file from Work Order’s file field
  2. Predict action to call our AI model and pass on the image
  3. Based on the prediction, either mark Work Order as Closed or send an email to Field Technician

Here is our Power Automate flow:

..the second step:

the third and following steps


All done! Start the play by uploading the image of completed work (in this case 1×2 or 4×4 lego brick images). The flow will run, send the image to AI model, and update the status of Work Order or send the email. Successful output:

Viola! That was fun and what we just experimented with is, in fact, a game changer in terms of making enterprise applications (like Dynamics 365 Field Service) really smarter – coupled with the fact that you can get this up and running in a very short timeframe and without expensive solution development/deployment.

Hope this was useful. If you have any suggestions/questions, please do reach out – would love to hear from you.

Posted on

Setting up Work Order Types and Incident Types

The Work Order entity in Dynamics 365 Field Service has few fields which look trivial in the first glance but are critically important for system design and for enabling the intended experience for customers. Two such fields are Work Order Type and Incident Type.

In one of the recent projects, we literally spent hours (read: days) on discussions to finalise the right values for these fields. That was a prompt for me to write an article on how to set up these fields and share some recommendations.

The key starting point is that these fields are part of ‘Field Service’ administration and generally the best practice is to either identify all types in the beginning sprints (or weeks) of the project or at least agree on the definition of what each of these different types is to be used in the context of the project. Also important to mention, these fields and possible values for each of them is configured under Settings area of Field Service.

Work Order Type is used to categorise work orders at the top level. The ‘top-level’ is important because this is the first level of categorisation of what work order is about (incident type provide the second level of categorisation in terms of what work needs to be done). Following is a snapshot of out of the box Work Order Types and Incident Types:

There are few takeaways here:

  1. Notice that coloured boxes (Diagnosis & Repair, Inspection and Install or replace) are Work Order Types. They are a higher level of categorisation of work, e.g. if work order’s type is ’Diagnosis & Repair’ it can be quickly established that work under that work order will entail some sort of maintenance, and not installations or construction.
  2. The Incident Type under each Work Order Type gives a further classification of work. It is important to remember here that there could be one or multiple Work Order Incidents under the same work order.
  3. Incident Types also links to resource skills, products and services, which gives a more granular level of control in terms of what products are required to do that kind of work, or what skills are required for resources to do that work etc.

Enough of theory, let’s see how things work in the system. Go to Field Service -> Settings -> Work Order Types

Work Order Types have three configurable properties:

  1. Taxable: Is the work taxable or not?
  2. Price list: Applicable price list for this type of work
  3. Incident Required: When this Work Order Type is selected, should the system automatically created Work Order Incident record?

You’ll notice ‘Incident Required’ is set as Yes for Diagnosis & Repair and No for Inspection.

On creating a work order of type Diagnosis & Repair, you’ll notice system automatically creates Work Order Incident record

However, in the case of work order of type Inspection, the system doesn’t create any Work Order Incident record leaving it for the user to create manually.

Hope this is useful. Feel free to share your feedback and if you have any queries related to Dynamics 365 Field Service, drop a message and I’d love to chat.

Posted on

Setting up Priorities for Work Orders

Can there be any scheduling without priorities?

Work Orders in Dynamics 365 Field Service can be optionally marked with priorities and this information shows up in Schedule Board to assist planners/dispatchers in managing bookings. This post is about how-to setup Work Order Priorities and then prioritise work order.

The Setup

Go to Field Service -> Settings -> Priorities

Click +New. A new form will open. Enter data (per the screenshot below) to set up ‘High’ priority.

Similarly, set Medium and Low.

Prioritise Work Order

Open Work Order, go to the ‘Settings’ tab and select ‘Priority’

View Priorities in Schedule Board

Priorities against Work Orders appear in the bottom panel of Schedule Board (Unscheduled Work Orders) and priority also appear on the top-right corner of the booking on Schedule Board:

The good thing about this #NoCode out of the box feature is the fact that (a) the number of priority levels, (b) colours for priority levels and (c) names of priority levels can be all tailored per the business requirements.

Hope you find this useful. Please feel free to share your feedback.

Posted on

The ‘Currency’ error on Work Order

I was reminded of this gem from XKCD today:

The context is a customer call who found this annoying error on the creation of a work order in Dynamics 365 Field Service:

The error message is a bit cryptic but what it means is simple: currency should be consistent on a work order AND records mentioned in work order. Three currency fields are at play here:

  1. Currency in the price list of a selected Billing Account
  2. Currency in the price list of a selected Work Order Type
  3. Currency in the price list of Work Order itself

If any of these three currencies are different, you’ll see this error on work order creation. For our customer, it turned out a change was made in price list without understanding the consequence here. The bottom line is:

Keep the currency and, in turn, price list consistent in Billing Account, Work Order and Work Order Type records.

Hope it helps. Thanks for reading!

Posted on

Work Orders – II

Work Order is the “work” itself – which is scheduled and then actioned by the field service staff. To understand how Work Orders works in the app, we are looking at three 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 the first part of this topic, we looked at the structure of the Work Order as an answer to the first question. The last two points are the focus of this post.

How Work Orders are created?
Work Orders are typically created in three ways:

  1. Manually. Basically go to Work Orders and clicking on ‘New’
  2. Case to Work Order. The out of the box feature allows a ‘conversion’ of a case into work order. This is typically used in those scenarios where a customer representative records a customer’s complaint as a case, but on investigation it is surfaced that resolution of a complaint may require a site visit or some device/area/asset needs to be fixed. In this case, this out of the box process, creates a new work order record and links it to case record automatically
  3. Preventative Maintenance Work Orders: These work orders are auto-generated by the system based on the agreement booking setup, type, frequency and other specifications that are configured in ‘agreement’ record as part of preventative maintenance setup

Above said, there could be business scenarios where you’d like to link creation of a work order to an existing system or a custom entity. As an example, you may want to create a work order from opportunity for the field service staff to go visit the customer site before finalising a quote. This can be achieved easily through using a Business Process Flow. If you’d rather want a button click user experience, then Power Automate could be used.

Status life cycle of Work Order from creation to completion
The most important thing to remember in this section is: we are talking about ‘System Status’ here – not Status and Status Reason fields that are part of almost every entity in Dynamics 365. The System Status field is a special field on Work Order which could be set to either of these values:

  • Open – Unscheduled
  • Open – Scheduled
  • Open – In Progress
  • Open – Completed
  • Closed – Posted
  • Closed – Canceled

The System Status is locked as no new status options can be introduced in it. In order to customise it for your business, you can use a Work Order Sub-Status records which can be added against each system status.

A typical life cycle of work order works like this:

  1. From creation, scheduling and on to completion:

Open – Unscheduled is the default first status of a newly created work order. This status changes to Open – Scheduled when booking is created against a work order. When work is started against booking, the status of work order changes to Open – Completed. Upon completion of all bookings against a work order, status of work order changes to Open – Completed. Some billing, reconciliation or confirmation of services may happen at this stage (offline) and then work order can be manually updated to Closed – Posted which essentially makes work order read-only as a final state of work order.

It is important to note here that the status of work order may switch between Open – Scheduled and Open – In Progress based on the status of booking records.

  1. If work order needs to be cancelled before scheduling any work, there are only two status changes:

An example of this is when a work is created for a customer but then needs to be cancelled due to a request from customer or unavailability of crew.

Further readings:

Posted on

Work Orders – I

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.