IoT commands and pulling device data

What it does

Commands are the outbound half of Connected Field Service: instructions sent from Dataverse back to a device to make it do something, change a setting or report data. Alongside them, Pull Device Data fetches the latest readings from a device on demand, so someone triaging an alert can see current state rather than the snapshot that tripped the rule.

Key facts

Commands are built from two setup tables. Settings > IoT > IoT Property Definitions defines the individual properties and their data types; Settings > IoT > Command Definitions assembles those properties into a named command such as "Reset Thermostat".
The property definition form has a Show string option that renders the message string being constructed. Use it — it's the only sanity check before you fire something at real hardware.
Commands are sent from the IoT alert record via Send Command: pick a command definition, then send. The command is stored in msdyn_iotdevicecommand.
What the command payload has to look like comes from the device manufacturer's manual or API documentation. Field Service has no idea what your device accepts; it constructs and delivers whatever you defined.
Pull Device Data sits on the IoT device record and on the customer asset ribbon when an asset has devices connected. Results appear under Device Data History on the device.
Device data is also pulled automatically when an IoT alert is raised, so an alert usually arrives with recent state attached.
Scheduled pulls are available when Azure IoT Hub is the provider: Settings > IoT > IoT Settings, Device Data Pulls tab, set Scheduled Data Pull to On and choose a frequency.
Under the covers these are provider actions — Pull Device Data, Register Device, Aggregated Device Readings, Query Device Readings and Get Device Events. Query Device Readings takes From, To, device ID and an ISO-8601 interval such as PT1M; Aggregated Device Readings takes a JSON list of measure, aggregate and time range.
The device readings chart is gone. It depended on Azure Time Series Insights, retired 7 July 2024, with Fabric as the documented migration target.
With the IoT Hub deployment, commands leave Dataverse through the Dynamics-to-Azure Logic App, which forwards to IoT Hub and on to the device.

When to use / skip

On-demand data pulls are worth having on almost any Connected Field Service deployment — they're cheap, they're already wired up, and they make an alert genuinely actionable.

Commands are a different proposition. Remote reset, remote reconfigure and "clear the fault without a visit" are the headline demos, and they are exactly the capability that justifies the project's business case. They're also the capability with real-world consequences: you are sending instructions to equipment on a customer's premises, sometimes safety-relevant equipment. Skip commands unless the client has an engineering owner who will sign off on which commands can be sent, by whom, and under what conditions. "The dispatcher can restart the chiller" is a decision for the client's engineering function, not for the Field Service workstream.

Scheduled pulls are the one to be careful with. They generate volume against the provider and, on IoT Hub, that volume has a cost. Use them where a periodic snapshot has a purpose, not as a substitute for proper telemetry streaming.

Configuration decisions

Which commands exist at all — start from the device's supported API, then cut the list down to what the business genuinely needs.
Who can send each command. There's no per-command permission model out of the box worth relying on, so the design usually comes down to who gets access to the Send Command action.
Whether commands are only ever sent from an alert, or whether you extend the action to the device or work order so a technician can act without a triggering alert.
Scheduled data pull frequency, weighed against the message cost and against what the client actually does with the readings.
Where historical readings go now that Time Series Insights has gone — Fabric, Azure Data Explorer, or accepting that you only keep what's in Device Data History.
Whether Query Device Readings and Aggregated Device Readings are worth implementing for your provider, or whether the alert payload alone is enough.

Gotchas

Command definitions are built by hand from property definitions. Get a data type or a property name wrong and the message goes out malformed; the device ignores it and nothing in Field Service tells you.
There's no built-in acknowledgement that the device did what it was told. If the client wants confirmation, that's a round trip you have to design, not something you switch on.
Send Command lives on the alert. Clients who expect to command a device directly from the asset or the mobile work order need that built.
Scheduled pulls are IoT Hub only. If you're on a custom provider and the client saw the setting in a demo, you'll be explaining that difference.
Anything in an old statement of work about device readings charts or Time Series Insights needs rewriting. That visualisation no longer ships.
Commands sent to a device that was never successfully registered fail quietly. Check Registration Status before debugging the command definition.

Consultant notes

Demo Pull Device Data early. It lands better than a command demo because it's low-risk and it visibly makes the alert more useful.
Get the manufacturer's device API documentation before you promise any specific command. Without it you're guessing at the payload shape, and you will guess wrong.
Push back on giving dispatchers unrestricted command rights. Frame it as a safety and liability question and the client will usually agree to a shortlist.
Before go-live, run each command against a simulated device and confirm the constructed string with Show string, then repeat against one real unit with the client's engineer watching.
If historical telemetry reporting is in scope, raise it as its own workstream with its own cost. Since Time Series Insights retired, it is not something Field Service gives you for free.

Worth revisiting once there's a documented Fabric-based replacement for device readings, or if command acknowledgement becomes first-party.