Work Order Lifecycle — Dynamics 365 Field Service
What is a Work Order in the Microsoft Dynamics 365 Field Service Application, and what is its Lifecycle?
What’s a Work Order?
Think of Work Orders as the ‘beating heart’ of the Microsoft Dynamics 365 Field Service application. They sit right at the core and represent the jobs that an organisation needs to carry out. These might include:
· Repairing a hardware fault
· Scheduled maintenance of assets
· Installation/Uninstallation of equipment
· Providing on-site quotes at the customer location (performed by Field Service Agents)
Work Orders are individual records which are organised into a table within Dataverse (not surprisingly, called Work Orders). This table is related to many other core tables allowing data to directly link to each Work Order.
Below are other core tables that are linked to the Work Order table:
· Billing Account (Account) — The Organisation that will be responsible for paying the invoice incurred by the Work Order carried out.
· Service Account (Account) — The Organisation that will be serviced by the Work Order. It’s where the asset belongs to and is the location of the work being carried out. (This may or may not be the same Organisation that pays the invoice — hence the separation between Billing Account and Service Account).
· Bookable Resource Booking — The resource booked to carry out the Work Order.
· Case — The case in which the Work Order relates to. Customer Service incidents (cases) can be used to trigger work orders.
· Internet of Things (IoT) Alert — For instances where an alert has been received from an IoT device, and a Work Order is generated for preventative maintenance.
· Resource Requirement — The list of requirements that is required from a resource in order to carry out a specific Work Order.
· Return Merchandise Authorisation (RMA) — Where a return of a product or notification of a faulty product by a customer directly relates to a specific Work Order.
· Return to Vendor (RTV) — Where a faulty / damaged product is to be returned to the vendor and relates directly to a specific Work Order.
· Return to Vendor (RTV) Product — The product that is to be returned to the vendor.
· Work Order Incident — The incident that has been reported by the customer which has resulted in the Work Order.
· Work Order Product — The product/s that are being used or serviced as part of the work order carried out.
· Work Order Service — The services that have been performed as part of the overall Work Order.
· Work Order Substatus — This is the specific status of a Work Order.
· Work Order Task — Specific tasks that need to be carried out as part of an overall Work Order.
· Work Order Type — This defines the type of Work Order being carried out.
There are more tables linked to the Work Order table, but these are the key ones you’re likely to come across when utilising Work Orders. The below graphic gives you a view of the architecture surrounding the Work Order process.
What are the statuses of a Work Order?
Microsoft Dynamics 365 Field Service provides system statuses which can each be mapped to one or more Work Order sub-statuses. The system status is generally the higher level, and the substatus is the more precise level.
Substatus records can be created manually to include as many different customised substatuses as required.
Different substatuses could be used for different types of Work Orders or scenarios, or they could be used to better describe the actual stage in the Work Order lifecycle.
The Work Order system statuses are:
- Unscheduled
- Scheduled
- In Progress
- Completed
- Posted
- Canceled
So, for an example, you might decide that within the context of your process, the Work Order system status “Unscheduled” requires the following sub-statuses in order to best indicate where a particular Work Order is within the process:
- To be Processed
- Assigned
- Unassigned
- Awaiting Scheduling
Alternatively, you might decide to have one substatus for each system status and make only the substatus visible on the Work Order form. (Both fields are on the form by default):
If you have multiple substatus per system status, there are various options available for setting the relevant one. You could use:
- Workflows — e.g. if a specific substatus needs to be set based on the work order type.
- Power Automate — e.g. if the substatus needs to be set based on a change made to a SharePoint list.
- Azure Logic Apps — e.g. if the substatus needs to be updated based on a status change in another system, such as a portal.
Each substatus needs to be mapped to a system status and you can select which substatus is the default for each system status.
It is strongly recommended the ‘System Statuses’ choices column’s values are not changed as there are background processes/system jobs that rely on these. Instead, admins are advised to edit the labels of the System Status from within the choice column should they need these statuses to display differently in the UI.
Below are some more examples of Work Order system statuses and Work Order substatuses, mapped to the system status:
Microsoft Dynamics 365 Field Service allows you to select which system status is used by default for completed work orders:
It also allows you to select whether an invoice is created based on a “Posted” system status:
If you select the option “On Work Order Posted”, carefully consider the default substatus under the “Posted” system status, given the invoice wouldn’t be created until that point.
For example, a substatus like “Payment Received” wouldn’t really work as the default. It would be better to use “Invoice Generated” as the default and implement some logic to update the substatus to “Payment Received” when an invoice is completed / closed.
What are Booking Statuses?
Booking statuses are used on the bookable resource table, to help you track a particular booking through the process.
Microsoft Dynamics 365 Field Service provides several default booking statuses:
· Scheduled
· Committed
· Traveling
· In Progress
· On Break
· Completed
· Cancelled
The booking statuses can be amended, and custom statuses can be added.
So, what is the Work Order lifecycle?
Logically, we can simplify the work order lifecycle into five high-level categories:
· Created
· Scheduled
· In Progress
· Completed
· Cancelled
Created:
A customer raises an incident when a piece of equipment becomes faulty. This creates a case in the application which, in turn, triggers a work order for repairing the faulty equipment.
The work order is created, and the system status is (by default) set to “Unscheduled” and the substatus to “Received”.
Scheduled:
Using the tools available within the application, such as the Schedule Board, the dispatcher finds a suitable resource for the job and a date/time slot that works for both the customer and the engineer. They then schedule the work order.
The work order is scheduled; the system status is set to “Scheduled” and the substatus set to “Booked”.
In Progress:
Once the time comes for the work order to be carried out, the engineer updates the booking to specify they are travelling to the customer’s destination where the repair is to take place.
The work order system status is set to “In Progress” and the substatus is set to “On Route”.
Completed:
The engineer has fixed the faulty equipment, and it now works as expected. They update the booking to specify the equipment is now fixed.
The work order system status is set to “Completed” and the substatus set to “Repaired”.
The customer is then invoiced for the repair work and the payment is received.
The work order system status is set to “Posted” and the substatus set to “Payment Received”.
Cancelled:
If, before the time of booking, the customer informs the maintenance company that the equipment is now working as expected and it was a user error causing the original issue, the booking is cancelled by the dispatcher.
The work order system status is set to “Cancelled” and the substatus is set to “Not Required”.
Finally, you can use the Business Process Flow (BPF) to help users visualise the lifecycle of a work order, or the process it goes through.
Microsoft Dynamics 365 Field Service includes a BPF on the work order form by default, which looks like this:
Under each of the three stages (Work Order, Schedule Work Order, and Close Work Order) are steps used to guide users through each stage of the process and make it clear which data is needed or can be added/updated at each stage. It also helps keep the process and data consistent.
This Business Process Flow can be configured to include customised stages and steps which could better reflect the process / lifecycle of a work order in a particular organisation.
Learn more about configuring BPFs here: https://docs.microsoft.com/en-us/power-automate/create-business-process-flow
In today’s business landscape, it’s crucial for businesses to focus on critical areas that help reduce spend, minimise carbon emissions, and improve customer impact to meet strategic goals.
Learn more about Capgemini’s Connected Field Services solutions here: https://www.capgemini.com/solutions/connected-field-services/
If you want to learn more about the Microsoft Team here at Capgemini, take a look at our open roles and consider joining the team!
