What it does

Connected Field Service is the set of Dataverse tables, plugins and business process flows that let device telemetry land in Field Service as IoT alerts, and let those alerts turn into cases and work orders. The Azure IoT Hub flavour of it is a reference deployment: you run a Microsoft-published ARM template into your own Azure subscription, and it stands up the IoT Hub, Stream Analytics, Service Bus and Logic Apps that do the actual work.

Key facts

• The Dataverse side ships with Field Service. The Azure side does not — it's an ARM template you deploy yourself from the microsoft/Dynamics-365-Connected-Field-Service-Deployment GitHub repo, and every resource it creates bills to your subscription.
• The template deploys an Azure IoT Hub, Stream Analytics jobs, a Service Bus namespace with queues, a storage account holding devicerules.json, and a commondataservice API Connection. A SQL Server for Power BI reporting is optional.
• Data path is: device to IoT Hub, Stream Analytics evaluates threshold rules, matches go onto a Service Bus queue, a Logic App writes an msdyn_iotalert record into Dataverse. Commands go back out through a second Logic App.
• Core tables are msdyn_iotalert, msdyn_iotdevice, msdyn_iotdevicecommand and msdyn_iotdeviceregistrationhistory.
• You need System Administrator plus the IoT - Administrator role in Dataverse, and Owner, Coadministrator, Service Administrator or Account Administrator on the Azure subscription.
• Only work or school accounts can deploy it, and only into one Azure tenant — you see subscriptions in the primary directory of the signed-in account, so a guest invitation to another tenant's subscription doesn't help.
• The deploying account needs the CRM API Management Access permission in the Entra tenant.
• Post-deploy there are several manual wiring steps the template does not do for you: create the IoT Provider Instance record, point the IoT Message service endpoint at the Service Bus queue using the Plugin Registration Tool, authorise the commondataservice API Connection, upload devicerules.json to a devicerules container, and start the Stream Analytics jobs.
• The device readings chart is gone. It ran on Azure Time Series Insights, which Microsoft retired on 7 July 2024; the documented path forward is Fabric.
• Thresholds live in devicerules.json and in the Stream Analytics query, not in Dataverse. Changing what counts as an alert is an Azure change, not a Field Service configuration change.

When to use / skip

Most Field Service projects do not need this. If the client's ask is "we want to see asset data on the work order", that's usually a reporting or integration problem, not a Connected Field Service problem. Reach for it when there is genuinely a fleet of connected assets, someone owns the Azure estate, and the business case is fewer truck rolls because faults are detected before the customer phones in.

Be honest about what this deployment is: a working reference architecture with Microsoft's name on it, not a managed service. You are taking on Stream Analytics queries and Logic Apps that your client will run, monitor and pay for long after go-live. If they have no Azure capability and no appetite to build one, scope that in properly.

If the devices already report into something else — a manufacturer's own cloud, a building management system, a third-party IoT platform — skip the template and integrate to the IoT provider framework instead. It's less work and it doesn't duplicate a telemetry pipeline the client already pays for.

Configuration decisions

• Whether to deploy the Microsoft ARM template at all, or write your own integration against the IoT provider tables using a telemetry platform the client already runs.
• Which Azure subscription and tenant the resources sit in, and who owns them after go-live — this is a one-way-ish decision, since the tenant is fixed by the deploying account's primary directory.
• Region for the Azure resources. Match the Field Service environment's region or accept the latency and the data residency conversation.
• Where fault detection logic lives: Stream Analytics thresholds in Azure, or richer rules pushed downstream into Dataverse after the alert is raised.
• IoT Hub tier and message volume assumptions, which drive most of the running cost.
• Whether to keep the optional SQL Server and Power BI reporting leg, or send historical telemetry to Fabric or Azure Data Explorer instead now that Time Series Insights has gone.

Gotchas

• The ARM template gets you maybe 70% of the way. The Plugin Registration Tool step for the IoT Message service endpoint catches people out every time — the Service Bus hostname needs the sb:// prefix and the queue name is the one ending in -crm.
• Stream Analytics jobs are deployed stopped. Nothing flows and nothing errors; alerts just never appear. Check the job state first when telemetry seems to vanish.
• The commondataservice API Connection has to be authorised interactively with a Dynamics 365 account. Use a service account, not the consultant's own — otherwise the connection dies when their access is removed.
• Azure costs are entirely outside the Field Service licence and land on the client's subscription. Get that in writing before the first demo, because a demo IoT Hub costs nothing and a production one doesn't.
• The device readings chart is no longer available, so any statement of work written from older Connected Field Service material promises a visualisation that doesn't exist any more. Check what you've committed to.
• Field Service documentation now describes IoT Hub and custom providers as the integration routes. If a client's earlier design references an IoT Central connector, re-verify it against current docs before building on it.

Consultant notes

• Demo with the device simulator, not real hardware. It's designed for exactly this and it removes the "our sensors aren't installed yet" blocker from the first workshop.
• Split the delivery in two: the Azure telemetry pipeline and the Field Service alert-to-work-order process. They need different people, and the Field Service half can be proven with manually created alert records while Azure is still being built.
• Push back hard on threshold rules being "configurable by the business". They live in a Stream Analytics query. If the client wants business users tuning thresholds, that's a design item with a real cost, not a checkbox.
• Before go-live, confirm the client has named an owner for the Azure resource group, and that alerting exists on the Service Bus queue depth and Logic App run failures. Silent failure here looks identical to "no faults today".

---

Worth another look if Microsoft refreshes the deployment template, or once the Fabric replacement for device readings has a documented Field Service story.