Dynamics 365 Field Service and IoT – Technology Stack and Approaches

In the previous article, we looked at the fundamental premise of connecting IoT devices with Dynamics 365 Field Service. Today let’s have a look at various technology options for enabling this conversation between IoT devices and Dynamics 365. There are essentially three different approaches while working with Azure and Dynamics 365 Field Service:

  1. Azure IoT Central with Dynamics 365 Field Service
  2. Azure IoT Hub with Connected Field Service
  3. Third-party with Dynamics 365 Field Service

Let’s delve into details of each of these approaches for further details:

1. Azure IoT Central with Dynamics 365 Field Service

First thing first, a quick introduction to Azure IoT Central:

Azure IoT Central is cloud-based web application (SaaS) that is capable of (a) connecting with a variety of IoT devices, (b) centrally manage, and (c) provides a mechanism to integrate with business apps

Azure IoT Central also comes with a variety of industry accelerators (open source as well) which further helps in getting an IoT portal up and running pretty quickly. As IoT Central receives signals and alerts from devices, you could define rules (above or below a certain range, for example) and based on those rules, alerts could be sent to Dynamics 365 Field Service using Power Automate flows.

Pros ✅ and Cons ❎:

  • Simple architecture ✅
  • Short time to market ✅
  • Doesn’t require specialised skills ✅
  • Customisations are not possible ❎
  • Device-level services are not exposed ❎

2. Azure IoT Hub with Connected Field Service

Introducing Azure IoT Hub and Connected Field Service first:

Azure IoT Hub is a full-fledged cloud-based PaaS that connects to both IoT and Edge devices, ensure secure communication channel between cloud and devices, is able to support bi-directional communication with millions of devices and fully integrates with other Azure products like Event Grid, IoT Edge, Stack Hub, Machine Learning etc.

Connected Field Service is a solution that (a) Dynamics 365 model-driven app, (b) Dataverse information structure for IoT devices, alerts etc., and (c) a capability to integrate with Azure IoT Central and Azure IoT Hub.

Connected Field Service provides a mechanism to setup Azure IoT Hub and related products (e.g. Azure Logic Apps to communicate with Dynamics 365, Azure App Services etc.) seamlessly using a wizard. This solution stack serves as a powerful platform for integrating and listening to millions of devices securely, communicate two-way, ensure device-level authentication, and tight coupling with business rules in Dynamics 365.

Pros ✅ and Cons ❎:

  • Powerful customisation options ✅
  • Device-level controls ✅
  • Supports a variety of protocols and SDK for major languages ✅
  • Cost can be fine-tuned based on consumption ❎
  • Requires specialised skills to setup and monitor ❎

3. Third Party with Dynamics 365 Field Service

Thanks to Azure and Power Automate, any third party IoT SaaS or PaaS solution can send IoT alerts or receive commands from Dynamics 365 Field Service and Connected Field Service. The benefits of integrating a third-party IoT system with business applications are many: from end-to-end business coverage to bringing the element of proactivity (versus reactivity) in services portfolio. There are numerous examples of Dynamics 365 Field Service ingesting devices data through Azure or sending commands based on business rules.

This concludes the overview of various technology approaches that are available for IoT devices to talk to Dynamics 365 Field Service. The next article in this series will be hands-on walkthrough of the first approach.

Thanks for reading!

Dynamics 365 Field Service and IoT – The Complete Guide

Whenever I talk to customers or within #Dynamics365 community, one of the most FAQs is about IoT (Internet of Things). Nothing garners as much interest as this one. Is IoT just a buzzword or a reality? How does it work with Field Service – or why in the first place IoT has anything to do with Field Service? Does it require any specialized skill set?

Photo by Ruiyang Zhang on Pexels.com

I intend to cover all about IoT and Dynamics 365 Field Service in this series of post. This has been in my mind for some time but I was waiting for the release plan for 2021 Release Wave 2 to ensure we cover some upcoming features as well. Now before we start, just to make scope clear (pun intended) my goal is to:

  • Address the philosophy before jumping on to nuts & bots: why IoT, different approaches, tech stack etc.
  • Present a walk-through of technology nuts & bolts of various IoT approaches
  • Share a future roadmap for further learning and specialisation

… and the only pre-requisite here is familiarity with Dynamics 365 as a platform.

The Series

Here is a series of posts that are part of this guide:

  1. Introduction
  2. Technology Stack and Approaches
  3. CFS with Azure IoT Hub – The Setup
  4. CFS wit Azure IoT Hub – Device Registration and Monitoring [TBD]
  5. Azure IoT Central – The Setup [TBD]
  6. CFS with Azure IoT Central [TBD]
  7. New Features [TBD]
  8. FAQs and Further to explore [TBD]

Why IoT with D365 Field Service?

Let’s start with answering the fundamental question:

What is the basic premise of using Field Service in IoT?

Every business having equipment and assets (think utilities, facility management, LGAs etc.) wants zero down-time i.e. those equipment, devices and assets should be up and running without ideally any outage. This ambition is realized by having two kinds of maintenance:

  • Preventative Maintenance: Every equipment comes with a recommended service calendar. We all know about cars: they need to be serviced every few thousand miles/kilometres or few months. This is called preventative maintenance because it preempts issues or breakdowns by having key components checked, serviced or replaced regularly. It statistically doesn’t bring outages down to zero but it does reduce the possibility significantly.
  • Reactive Maintenance: Once equipment stops working, then fixing it asap, troubleshooting, finding a workaround or making a permanent fix etc. – all comes under the heading of reactive maintenance. In other words, this is ‘break-fix’

Beside others, a key difference between these two types of maintenance is in the way their business process starts:

  • Preventative Maintenance starts with having a service calendar of assets and then following it properly,
  • Reactive Maintenance begins with a call, ticket or an email from customer (somebody will notice that equipment is not working and then call for break-fix)

‘Somebody’ and ‘notice’ in Reactive Maintenance are keywords because they are weak links in the entire process. If somebody makes a mistake and doesn’t notice a faulty equipment, or identify the wrong equipment, or does notice but report late etc. – then equipment’s overall ‘up-time’ will reduce. This prompts a question: can we optimize this process or in other words, instead of reactive, can we have a proactive maintenance? The answer is: yes!

  • Proactive Maintenance: When an equipment/device/asset sends an alert signal identifying (a) an issue or (b) a deviation from standard values, then troubleshoot and fix the potential problem.

Since signals would be caught automatically (without manual noticing), investigation and break-fix would happen earlier. Many times such signal identify a potential problem which may happen few days, weeks or months down the line. This makes Proactive Maintenance a key part of services and maintenance portfolio in every industry and therefore IoT (signals, alerts from equipment) works with Dynamics 365 Field Service.

Hope this makes a case for ‘Why’ behind this series. In this next post, we’ll talk about the ‘How’. That is, we will look at various IoT deployment models and approaches with Dynamics 365 Field Service.

Thanks for reading!

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

2021 Release Wave 2 Plan – Top 5 Features [2/2]

Continuing the review of Release Wave 2, this is the second post in this series. As I am going through 2021 Release Wave 2 documents (Dynamics 365 and Power Platform), it is great to see so many amazing features are on the way. It is evident that innovation and product enhancements are underway in all three areas – propelling the entire platform’s growth:

  • each product is getting stronger with the organic enhancement of existing features and/or introduction of new capabilities,
  • products are complementing each other resulting in a sum greater than parts (eg. Dynamics 365+ Teams, Power Automate + Dynamics 365 etc.), and
  • Trickle-down effect of all these improvements into specialized industry vertical products

Let’s jump on to few more ‘Top 5’ features:

Thanks for reading!

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

2021 Release Wave 2 Plan – Top 5 Features [1/2]

The plan for Release Wave 2 is out last week and it is time to check out the exciting list of all the amazing features arriving later this year. Since this is a long document (in addition to a similar plan for Power Apps), this post will be an-going series as I read, rank and share top 5 features per product/app. Are you ready? 😀

More to come later.. watch this space.

Thanks for reading!

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

Exploring and Setting up ‘Track Technician Location’ in 30 minutes

One of the *biggest* and *flashiest* highlights of the latest release wave (2021 Release Wave 1) is the ability for customers to (a) view arrival times, (b) see a live view of a technician on the way in a map, and (c) receive emails/SMS notifications. All of this further solidifies Dynamics 365 Field Service’s position as the market leader in this space and therefore, I couldn’t hide my excitement when I saw this feature arriving in my Dynamics 365 environment 😋. Following is an account and a quick guide on how to make it work in your environment: 

Photo by RODNAE Productions on Pexels.com


1. Having an Outlook 365 based email account

2. Setup ‘Twilio’ account for sending SMS (this could be a trial too)

Setting it up

Setup Portal

Go to PowerApps maker portal and create a new portal based on ‘Field Service’ template (see my previous post on how to set it up).


Go to ‘Field Service’ model-driven app -> Settings and click on ‘Customer Portal’ (scroll down):

Turn ‘ON’ Track My Technician feature and other messages. These ‘messages’ helps you decide list of events on which notifications should be sent to customers. For example, you may want to send notification on rescheduling but not on booking cancellations.

Next see those two Power Automate flow on the right? These Power Automate flows are responsible to send emails and SMS. Click on the first one (SMS):

Click on Edit:

Connect your Microsoft Dataverse and Twilio connections:

Leave rest of the Power Automate flow as it is:

Save and turn the flow ON:

Now, click on the other Power Automate flow, setup connections and turn flow ON. Nice and simple, no changes:

Optionally, you can (a) exclude Work Types on which notifications or technician tracking shouldn’t happen, and (b) exclude customers from this feature:

Next go to ‘Track My Technician’ tab and turn all features ON:

Let’s Try It Out 😀

All done – time for now. Let’s create a new Work Order and book a resource:

Oh and one thing – your booked resource should have Start and End Location set as ‘Resource Address’:

Check your email and phone now. You will start receiving notifications for booking reminders and as technician gets on the way:


For further reading, have a look at Microsoft Docs article. It is also worth exploring how backend of this solution works. Hint: check out Notifications table (I will write about that soon 😁).

Thanks for reading!

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

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 😊

Quickly Create New ‘Incident Types’

“What is the single most-effective productivity hack that exists in the world today?” Somebody responded, “Copy-Paste” to the question above – and at least, to me that makes a lot of sense. Copy-paste does have a literal meaning (which is also effective, if done smartly 😃) but more abstractly, copy-paste means to reuse previous work or maximize outcomes of already expended efforts. One way to do this is to use: templates.

In the world of Dynamics 365 Field Service, templates are called ‘Incident Types’. These are service templates that correspond to those services that are often delivered by field service organisations while using the same materials, checklists, series of steps etc. The logic dictates and experience has shown that a bulk of services (~80%-90%) in any organisation comprises of such repeatable but common set of work or service types. Dynamics 365 Field Service makes life easier for planners and schedulers to set up these templates once (with products, services, service tasks etc.) and then reuse them when creating new Work Orders.

This post reviews a new feature, introduced as part of 2021 Release Wave 1, which now allows creating Incident Types from Work Orders itself. Why this is a big deal? Well, previously you need to set up these templates (read: Incident Types) first and then use them. This might be difficult sometimes if not all templates are properly identified. Now with this new feature, you can start to create Work Orders and when you feel a certain Work Order is a representation of ‘repeatable work’, you can click on this new feature to create a template from the work order itself and use that template in future! Pretty cool, isn’t it 😎.

Set up and Play

Step 1

Create a new Work Order and make all the usual data entry and selections:

Optionally select any existing Incident Type

Add Products, Services and Service Tasks.

Service Tasks

Step 2

Click on the new ‘Create Incident Type’ button on the top:

This will open a window similar to below image.

This window lets us select which ‘parts’ of the existing Work Order (such as Products, Services, Service Tasks etc.) should be added in the new Incident Type by Dynamics 365 Field Service. I think this is the best part of this feature as it really hands over the control of the feature to users to properly configure templates, based on business patterns. This is truly awesome 💪. Click on the button to create new Incident Type:

Step 3

When you click Yes on the above message (or navigate through Settings -> Incident Types), you will see a brand-new Incident Type with all the constituents (Products, Services, Service Tasks etc.) as they were selected in previous screen. This Incident Type can be used in new Work Orders now.

Service Tasks


Does this impact an existing Work Order in any way? No, it doesn’t. The new Incident Type is created for future use. Lastly, I think this is one of those features in this release wave which is going to be used extensively. For reading further on Incident Types, have a look at this Microsoft article. Happy D365-ing.

Thanks for reading!

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

How to Hide Tax Fields? 🤔

Do you calculate taxes in Dynamics 365 Field Service? In my experience, most of the implementations do not use this feature due to several reasons, such as:

  1. Services (Work Orders) being managed by Dynamics 365 Field Service are being provided to internal customers (eg. servicing internal assets) or services are not taxable in the first place (eg. council providing city services)
  2. In many businesses services are not costed on an individual level, instead, they are covered as part of a larger contract. In this case too, invoicing (and therefore tax calculations) becomes irrelevant
  3. ERPs in many businesses manage taxes due to complexities or just as a standard way of doing businesses

Don’t take me wrong, tax calculations from products to services, and from work orders to agreements, is one of the strongest features of Dynamics 365 Field Service. However, since this feature is not used in many implementations, often developers have to hide these fields to improve user experience.

Well, guess what – you don’t need to spend those extra efforts anymore. A simple flag setting has solved that challenge.


Following are a few screens on which Tax fields are visible:

Making a change

There is a new flag added in the Settings screen of Field Service. Just flick it to say ‘NO’


Viewing those screens again, you will notice Tax fields (or in some cases, entire section) got hidden automatically.


Microsoft Docs page has a list of tables and forms on which flicking of that settings switch makes Tax fields visible or hidden. Pretty cool, I’d say 😃.

Thanks for reading!

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

Quick Tip: How to enable maps on your Dynamics 365 environment?

You set up a brand new Dynamics 365 environment, create a Bookable Resource and are pumped up to see map and routing work on the mobile app, but then you see the following error on a map – sounds familiar?

Map is disabled for this organization.

This was a story of my life in the last couple of hours – so thought to document resolution steps to save time in future 😊.

Step 1

Go to ‘Resource Scheduling’ app and then Settings. Click on Scheduling Parameters. Click to select ‘Yes’ against Connect to Maps.

Step 2

Go to Power Platform Admin Center, click on your environment and then click on Settings -> Features. Click to check ‘Bing Maps’

The Result

Go back to resource page now and yay! map is working. The map functionality will also get enabled this way on Schedule Board, Accounts, mobile app and other places.

Thanks for reading!

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

Unpacking the new Self Scheduling Portal

There are good days and then there are very good days in the life of consultants. Probably arrival of Self-Service Scheduling Portal (albeit in preview) falls in the later such events. The reasons are many but top of all is the fact: this was among the top of most requested features in Dynamics 365 Field Service. I have seen with many implementations, once customers see, feel and touch the value that Dynamics 365 product in resource scheduling, mobile app, auto-generate work orders and bookings etc., the next thing they look for is to let the customer do the scheduling itself. It is akin to the trend in customer service: from capturing customer cases to self-service. With this quick intro, my today’s article is about my experience of setting the new Field Service portal, enabling the new self-scheduling feature, setting up pre-requisites and unpacking how it works. Let’s get started!

Step 1:

Go to Power Apps Maker Portal (https://make.powerapps.com). Select the correct environment, click on Create, scroll down to find and click on ‘Field Service.

Step 2:

Select Portal name and URL. Click ‘Create’

Step 3:

It may take a few minutes for the portal to be up and running. Time for some Netflix! (Nah just kidding, it won’t take that long 😊).

Step 4:

You’ll see portal appearing in the list of apps shortly.

Step 5:

Click on the portal to see blank page.

Step 6:

Viola! that was good. Go to Field Service app, click on Settings and you will see a new Customer Portal sub-menu option. Click on that to see our new customer portal (very similar to other Power Apps portal configurations).

Step 7:

Click to open the record. You will see options to:

  • setup Track My Technician
  • setup Self Scheduling

We’ll focus on the later today.

Step 8:

Go to the next tab to see Display Settings. This is where you can configure the UX part of the portal. Color, fonts, specific pages, logo etc. – all is configurable.

Step 9:

You can also click on the ‘Display Configuration’ link to configure text on home page and other elements of the portal.

Step 10:

Click ‘Save’ and refresh the portal a few times (since portal configuration are cached, it may take a little while to see changes happening on the portal).

Step 11:

Go to the new ‘Self Scheduling’ tab and you will see a bunch of settings related to this new function. I particularly liked the fact that ‘asset selection’ and ‘resource radius’ factors are configurable.

Step 12:

At this stage, if you click on ‘Book Service’ button on the portal, you will see an equivalent of BSOD (Blue Screen of Death):

Step 13:

We need to set a couple pre-requisites at this stage. First assign a role to your portal user.

Step 14:

Secondly, configure at least one ‘Incident Type’ with ‘Enable for C2’ selected. I am sure this field label will get changed as this feature rolls out from Preview to GA:

Step 15:

That’s it. Click on Self Scheduling option again on portal and you will see the page will appear with the following:

  1. Service product: this shows a list of products that are associated with the ‘Account’ that the logged-in user is linked with. In other words, these are the products for which you are booking a service
  2. Service types: a list of incident types
  3. Date and time selection
  4. Additional information: this is a configurable option

Step 16:

Click on Book, it may take a few seconds and then shows a confirmation. A little delay seems to indicate that the booking function happens synchronously.

Step 17:

Let’s go back to Dynamics 365 Field Service to see what happened behind the scenes. First a new Work Order is created. Note incidents and bookings are also created.

Step 18:

The selected product (Customer Asset) is also selected on the Work Order record.

Step 19:

What happened to the text that we put under ‘Additional Comment’? Well those are added as a Note under the booking record.


I think it is a very neat implementation: it uses the same Power Platform capabilities that we all are familiar with and the process to set it up is quick and easy. In the real world, there will be a lot of requirements for specific fields on the portal, or a change in process to schedule (approvals) etc., and may be those features are in pipeline but I also think the fact that this is all built on Power Apps, makes it super easy for us Dynamics 365-addicts to configure and customize it. If you’d like to learn more, I think the best place to refer is the standard documentation and Dian Taylor’s blog.

Thanks for reading!

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