Custom IoT providers and the provider action model

What it does

The IoT provider framework lets you plug any telemetry platform into Connected Field Service, not just Azure IoT Hub. You register a provider, declare which actions it supports, and implement those actions as plugins. Alerts from every source then land in one list in Field Service and behave the same way regardless of where they came from.

Key facts

Three tables carry the model. IoT Provider names the platform and declares which actions it supports. IoT Provider Instance is one deployment of that platform, in a one-to-many with the provider. IoT Device is a one-to-many under the instance.
Two Azure IoT Hubs means two provider instance records under one provider. The instance holds Provider Instance Id (the identifier in the source system) and a URL for the API endpoint or resource.
The actions a custom provider is expected to implement are msdyn_RegisterCustomDevice, msdyn_IoTGetDeviceHistory, msdyn_ExecuteIoTCommand and msdyn_PullIoTData.
On top of those, the configurable provider actions are Pull Device Data, Register Device, Aggregated Device Readings, Query Device Readings and Get Device Events. Get Device Events needs no new action — you register a plugin on msdyn_IoTGetDeviceEvents.
Register Device returns a RegistrationStatus of Unknown, Unregistered, In Progress, Registered or Error, plus a DeviceId and a message. Surface those honestly; the UI reads them directly.
Query Device Readings takes From, To, IoTDeviceId and an ISO-8601 Interval such as PT1M or P1D. Aggregated Device Readings takes a device ID and a JSON list of measure, aggregate, time range type and value.
Get Device Events returns events that render as pins on the chart, including an Entity and GUID so a pin can point back at a Dataverse record such as msdyn_workorder.
You can add custom actions against a provider beyond the predefined set, implemented the same way.
Microsoft documents four connection patterns: Dataverse API, webhooks, connectors and custom code — each with the trade-offs you'd expect between control and complexity.
The stated prerequisites are model-driven app development, C#/.NET and Visual Studio, and REST/OData familiarity. This is a developer workstream, not a configuration one.

When to use / skip

Use it when the telemetry already exists somewhere else. Manufacturers increasingly ship their own cloud with their equipment, clients often have a building management system or historian, and plenty of estates run on a third-party IoT platform bought long before Dynamics turned up. In all those cases the custom provider route is cheaper and less duplicative than standing up an IoT Hub alongside and shuttling data into it.

Skip it if the client has no existing platform and no strong preference. The IoT Hub deployment gives you a working pipeline out of the box; writing plugins to reach the same place is not a good use of budget.

Also skip it if the only requirement is "get alerts into Field Service". If nobody needs to pull data on demand, send commands or chart readings, you don't need a provider implementation at all — you need something that writes msdyn_iotalert rows. A Power Automate flow or an Azure Function against the Dataverse API does that in a fraction of the time. The provider framework earns its cost when you need the two-way actions.

Configuration decisions

Which of the actions you actually implement. Register Device and Pull Device Data are usually the minimum; commands and readings are separate decisions with separate costs.
Whether the integration pushes alerts into Dataverse or Field Service pulls from the platform, and how you handle retries and ordering either way.
How provider instances map to reality — per region, per customer, per physical gateway — because devices hang off instances and this shape is awkward to change later.
Authentication from the plugin to the external platform, and where those credentials live. Plugin sandbox constraints will shape this.
Whether you implement the readings actions at all, given the built-in chart's dependency on the retired Time Series Insights and what that means for visualisation.
Whether to add custom actions for platform-specific capabilities, or keep strictly to the predefined set for supportability.

Gotchas

Nothing warns you about an unimplemented action. The button is there, the user presses it, and it fails or does nothing. Hide what you haven't built.
Plugins run in the Dataverse sandbox with its timeout. A chatty external API or a slow historian query will blow through it, and the failure mode looks like a broken button rather than a timeout.
The device-to-provider-instance relationship is structural. Reorganising instances after you've registered a fleet means touching every device record.
Registration status is only as truthful as your implementation. Returning Registered when the external platform actually rejected the device produces a fleet that looks healthy and receives nothing.
The interval parameter on Query Device Readings is an ISO-8601 duration, not a number of minutes. It's a quiet source of wrong charts.
Skills matter here. This needs a Dataverse plugin developer, and Field Service functional consultants routinely underestimate it when scoping. It is not a configuration task.

Consultant notes

Ask early what the devices already report into. On more than half of real projects the answer removes the Azure IoT Hub deployment from scope entirely.
Scope the provider implementation action by action and price it that way. "Custom IoT integration" as a single line item is where these projects go wrong.
Demo with alerts arriving from the client's own platform as soon as you can, even before commands work. Seeing their own equipment in the alert list changes the conversation.
Push back on implementing readings actions unless someone can name what they'd do with the chart. Since Time Series Insights retired, the visualisation story is weaker than the older material suggests.
Before go-live, test the external platform being unavailable. Make sure alerts queue or retry rather than being lost, and that the UI doesn't hang while a plugin waits on a dead endpoint.

Worth another look if Microsoft extends the predefined action set, or publishes a reference custom provider implementation.