IoT device registration and asset linking

What it does

Registration is the handshake that makes a physical sensor known to both your IoT platform and Field Service. It creates an msdyn_iotdevice row in Dataverse tied to a device identity in Azure IoT Hub (or your custom provider), and lets you connect that device to a customer asset so telemetry has somewhere meaningful to land.

Key facts

Devices live under Assets > IoT Devices. Connected Field Service must already be wired to IoT Hub or a custom provider before any of this works.
Two directions of registration. Create the identity in Azure IoT Hub first and pull it in with Import Devices, or create the record in Field Service and hit Register, which generates a device ID and pushes it to IoT Hub.
The Registration Status field is where failures surface: Unknown, Unregistered, In Progress, Registered or Error, with a message. If registration silently didn't work, that field is your first stop — usually the Dataverse-to-Azure connection is broken or Azure is unreachable.
Every registration attempt is recorded, and you can see the history on the device record's Registration History tab. It's backed by msdyn_iotdeviceregistrationhistory.
The device record carries Device Id (the identity in the provider), Account, Category, Time Zone and a Simulated flag for development and test devices.
A device belongs to one IoT provider instance. Two IoT Hubs means two provider instance records, and each device points at one of them.
Linking to an asset is a separate step: open the customer asset, choose Connect Device, and a Connected Devices section appears on the asset.
One asset can have several devices connected. Additional ones go on through Related > Connections rather than the main button.
The Simulated flag matters in practice — it's how you keep test devices distinguishable once real hardware arrives, which it always does later than planned.
Registration is what makes commands and on-demand data pulls possible. An unregistered device row is just a note to yourself.

When to use / skip

There's no skipping this if you're doing IoT at all. The real question is who does it and when, and that's a genuine delivery decision rather than a technical one.

Three field scenarios drive the design: an engineer installs a new asset that already has a sensor in it, an engineer retrofits a sensor to an asset that's already out there, or an engineer is on site using device data to diagnose a fault. The first two mean registration and asset linking have to be doable in the field, or by someone in the back office off the back of a completed work order. If the client imagines a technician performing an Azure IoT Hub registration on a phone in a plant room, that needs to be corrected early.

For fleets of any size, one-at-a-time registration through the UI is not the answer. Bulk-provision identities in IoT Hub through its own tooling and import, or write the registration into whatever manufacturing or dispatch process already assigns serial numbers.

Configuration decisions

Which system is the master for device identity — IoT Hub or Field Service — because that decides whether you import or register outward, and you don't want both happening.
Device ID convention. Auto-generated IDs are fine until someone has to match a Dataverse row against a label on a physical box; a serial-number-derived ID usually pays for itself.
Who links devices to assets, and at what point in the process: at manufacture, at install off the work order, or centrally afterwards.
How Category is used, given it's the main dimension for grouping devices into anything sensible in views and reporting.
Whether one asset genuinely needs multiple devices, and how you'll present that to a technician who only cares about one reading.
How devices are decommissioned when an asset is replaced — deregistration, ownership transfer, and what happens to the historic alerts.

Gotchas

Registering from Field Service auto-generates the device ID. If your operations team expects to type in the serial number printed on the sensor, register from the IoT Hub side or set the ID deliberately before the record is created.
The asset link is a connection, not a lookup on the device form. People add the device, see no asset field, and conclude the link isn't possible.
Adding a second device to an asset is not the same action as the first. Connect Device covers the first; after that you're in Related > Connections, which is not obvious.
A device record created but never registered looks completely normal in the list. Put Registration Status on your device views or you'll ship a fleet of records that never receive anything.
Device records tie to an account. Get that wrong on install and the resulting work orders point at the wrong customer, which is worse than no work order.
Test devices left with Simulated unset pollute production reporting, and nobody notices until someone asks why the fault rate is odd.

Consultant notes

Work through the install-day journey with the client on a whiteboard before building anything. Registration is a process problem dressed as a configuration problem.
Demo the Registration History tab. It's the thing that makes support conversations tractable later, and it demonstrates that failures are visible rather than silent.
Insist on a naming and ID convention in the first workshop. Retrofitting one across a registered fleet is miserable.
Before go-live, check that whoever handles installs has a role that can actually register devices — the Connected Field Service roles are separate from the standard Field Service ones, and technicians usually don't have them by default.
Ask what happens when an asset is swapped under warranty. Most clients haven't thought about it, and it's the first real-world case that breaks a tidy device-to-asset model.

Worth another look if bulk registration gets a first-party UI, or if the device-to-asset relationship changes from a connection to something more direct.