One aspect of Dynamics 365 Field Service’s adaptability lies in the flexibility of its ‘status’ functionality, driving a meaningful work order lifecycle tailored to each organization. Field Service helps manage work orders and bookings across diverse use cases. This blog series explores critical status concepts:
- System Status and Substatus for Work Orders
- Booking Status and Field Service Status for Bookings
- Booking Status Impact on Work Orders Across Single and Multi-Booking Scenarios
Grasping these concepts allows organizations to leverage the solution’s functionality, optimize field service processes, and ultimately provide better customer service.
This blog will expand upon many of the concepts discussed in the existing work order and booking status documentation: Work order life cycle and statuses – Dynamics 365 Field Service | Microsoft Learn
Work Order Status Concepts: System Status and Substatus
System Status
Work orders in Dynamics 365 Field Service have a column called System Status which helps organizations manage their field service processes efficiently. There are six values available for System Status:
- Unscheduled: Work order has been created, but resources have not been assigned.
- Scheduled: Work order has resources assigned and is ready for execution.
- In Progress: Work order is currently being executed by the assigned resources.
- Completed: Work order has been executed and finished.
- Posted: Work order has been invoiced and is now closed.
- Cancelled: Work order has been cancelled and will not be executed.
As the documentation highlights, an organization must use this field as is because these values allow the FS solution to interpret the current state of the work order record and apply appropriate behaviors and validations. If this list is changed, it could cause many issues both immediately and unanticipated, down the line. New values in this list would not be interpretable by the solution. However, the Field Service solution has a powerful related concept that provides infinite flexibility which can be mapped directly to these System Status values.
Substatus
In Dynamics 365 Field Service, the Substatus table plays a crucial role in providing organizations with the ability to create meaningful states that are mapped to System Statuses. One noteworthy feature of the Substatus table is the option to define a “Default” Substatus for each mapped System Status. This default Substatus will be automatically applied when a work order transitions into the corresponding System Status through the out-of-the-box (OOTB) logic.
The Default Substatus feature within the Substatus table allows organizations to streamline their work order management process by automatically applying a predefined Substatus when a work order moves into a particular System Status using the out-of-the-box logic. This helps ensure consistency across work orders while still allowing for customization and adaptability when needed.
For example, if your organization has a default Substatus of “Pending Customer Confirmation” for the System Status “Scheduled,” any work order that moves into the “Scheduled” System Status due to the standard logic will automatically be assigned the “Pending Customer Confirmation” Substatus. This helps maintain consistency and simplify the management of work orders, especially when dealing with a high volume of work orders.
It’s important to note that if a work order already has a different Substatus applied within the same System Status, the default Substatus will not be applied. This means that, if an organization adds custom logic to set a substatus, the default logic will not override it. The existing Substatus will remain in place, allowing organizations to maintain flexibility and customization for specific work order situations. It is also worth noting that any custom logic is still subject the allowed System Status validations (for example: the Work Order cannot be forced into a Scheduled System Status if there are no bookings).
Further, direct updates to the Substatus field will drive updates to the work order’s System Status, within the allowable System Status changes. For example, using some of the Substatus records proposed below, if a work order is in the “Technician Assignment Pending” Substatus, which maps to the Unscheduled System Status, a user could change the Substatus directly to “Customer Canceled” which will immediately move the System Status of the work order to Canceled. It is worth noting that the default form UI should filter the available Substatus values to allowed changes, based on the current state of the work order and the mapped System Status of the Substatus. In this example, none of the Subtatuses which mapped to the Scheduled or In Progress System Statuses would have shown up in the UI. They would have been dynamically filtered out so that a user couldn’t make a choice that wouldn’t have been allowed.
Example: Substatus Records with Mapped System Status
The following are an example set of possible meaningful Work Order Substatuses. These Substatuses will be mapped to the appropriate System Status to help drive actions and behaviors in the system while communicating meaningful information to anyone who looks at the work order in Dynamics 365 Field Service.
| Substatus | Mapped System Status | Default Substatus | What it communicates to the user who glances at the work order |
| Technician Assignment Pending | Unscheduled | Yes | The work order has been created, but no technician has been assigned yet. |
| Awaiting Parts | Unscheduled | No | The work order requires special parts which are on order and the required parts are pending delivery to the job site or warehouse. |
| Pending Customer Confirmation | Scheduled | Yes | The work order has been tentatively scheduled and the booking is awaiting confirmation from the customer regarding their preferred appointment time or other necessary details. |
| Appointment Confirmed | Scheduled | No | The work order has been scheduled and the customer has confirmed the appointment time. Every reasonable effort should be made to meet the commitment made with the customer. |
| Remote Support Scheduled | Scheduled | No | What is communicates to the user who glances at the work order: The work order has been scheduled for remote support, such as a software installation or configuration. |
| Service In Progress | In Progress | Yes | The technician is performing the service. |
| Work Order Completed – Successful | Completed | Yes | The work order has been successfully completed, and the scope of the work order has been resolved. |
| Work Order Unresolved | Completed | No | The bookings have been completed, but the scope of the work order has not be resolved. Additional action may be required, such as escalating the issue to a higher-level technician or recommending alternative solutions to the customer. |
| Work Order Invoiced | Posted | Yes | The work order has been invoiced, and the billing process is complete. |
| Customer Cancelled | Cancelled | Yes | The work order has been cancelled by the customer. |
| Resolved Remotely | Cancelled | No | The work order has been cancelled because the issue was able to be resolved remotely by customer service. |
Conclusion
While these are examples of Substatuses which may be valuable, each organization can create their own, set the defaults that make sense, and map them to relevant System Status values.
Next up in the blog series –
Part 2 – Booking Status Concepts: Booking Status and Field Service Status
Part 3 – Booking status impact on work orders across single and multi-booking scenarios
