Implementing Dynamics 365 Field Service – 3 anti-patterns

Anti-patterns are generally defined as

These are those commonly suggested and used solutions, which actually don’t work although they may seem like working. They are usually a product of gut-feeling, imperfect analogies (comparing the situations when they are actually different), and due to lack of understanding of how the system works (and why the solution won’t work). In this article, I will share my three (3) learnings around Dynamics 365 Field Service implementations in the recent few years.

1. Changes in execution pipeline of Work Orders

Consider these scenarios:

1. The customer is looking for running complex business logic to identify the priority of Work Order. Can we create a plug-in on saving of Work Order?
2. The costing of Work Order works in a very complex way through an integration with a legacy system. Can we call a runtime workflow on the saving of Work Order for calculations?

No, do not do that.

Runtime workflow or plug-in might be okay in case of other tables in Dynamics 365 like Cases, Opportunities etc. however when it comes to Work Order, adding any synchronous operation in the execution pipeline is strongly discouraged. This is because the system already does a lot of synchronous operations on the creation of work orders and adding anything to that, could result in data inconsistencies and performance issues.

2. Pilot launch with RSO

It is very common for Dynamics 365 Field Service clients to aim for the blue sky of ‘automatic optimised booking’ in the first rollout of the system. Resist this temptation, it just doesn’t work that way. Generally speaking, the introduction of Dynamics 365 Field Service in the service organisation is coupled with the cultural shift and business processes transformation. The scheduling component of Dynamics 365 Field Service relies heavily on the setup of resources, incident types, and other configuration data. Without having any benchmark and historical data of previous work orders, setting up Resource Scheduling Optimisation (RSO) plug-in to automatically create bookings never yields any benefits.

Always aim for a launch of Dynamics 365 Field Service as early on as possible, incrementally improve the configuration data (estimated duration per incident type etc.) based on gathered data, and then aim for introducing RSO in the third stage.

3. Modifying Inventory Journal, Booking Journal and Booking Timestamp records

Is it possible to modify these tables and make changes in their data? Yes. Should you be making these modifications and changes manually? Strictly, No. The data is inserted into these tables by the underlying processes of Dynamics 365 Field Service and any changes could result in either failing of those processes or lead to data inconsistencies. If there is a business requirement to use data maintained in these tables, create custom tables related to the above tables and let the business process, Power Automate flows, plug-ins etc. run on them.

Thanks for reading!

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

Say hi on Twitter and subscribe here if you’d like to get my new posts (on Dynamics 365, Azure AI and IoT) via email (roughly weekly).