Implementing Dynamics 365 Field Service – 3 anti-patterns

Anti-patterns are generally defined as

a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.

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 😊

AI-100 and the impact of AI on enterprise software

Finally, done! I was working on this weekend project since last 6 months and while learning new tech, products and features is always fun, what was really educating for me is the extent of commoditisation of AI on Azure platform.

There are many features such as real-time translation in dozens of language, finding celebrity, scene, retail brands in streaming videos, real-time moderation of images and text etc. are all accessible through simple API calls (and it is cheap too!). Secondly, AI models can be downloaded on-premise and on IoT devices, which makes data, processing and even Azure subscription costs lower. Lastly, conversational AI experience is not only easy to build but also comes with a number of tools/products to have a better conversation with users (employees and customers).

The bottom line is these AI capabilities are accessible to engineers, developers and programmers – not just to data scientists and AI specialists. And I believe the true transformative effects of commoditised AI is yet to be seen in enterprise software design and experience. As We are still in the early days of this transition. Exciting times ahead!

On certifications

Certifications matter. Those who say otherwise, are wrong. Yes, there was a time when it was *easy* to pass Microsoft certifications, not anymore.

What has changed?

  1. Quality of certifications has improved. Questions are based on understanding and the best use of features vs requirement. Case studies are part of exams. The balance of memory vs analysis questions has improved.
  2. You learn to work on new technology in two ways: read the documentation and go thru tutorials to do experimentation. Microsoft Docs and Microsoft Learn are two of the best resources for practitioners to do just; high-quality, high coverage and easy to practice content.

So, why you should consider getting certified?

  1. To gain recognition: increase your employability, with not-so-easy-to-pass certs, credentials proof your skills.
  2. To gain self-confidence on the new features/products. Microsoft products (across the board) are improving at a very rapid pace (a lot of them have weekly deployment schedules), keeping up is not easy, so certs give you confidence that you know what you are talking about.

Next stop:

Microsoft Learn: https://docs.microsoft.com/en-us/learn/

Microsoft Docs: https://docs.microsoft.com/en-au/

Also published as twitter thread.