IoT alerts and turning them into work orders

What it does

An IoT alert is a Dataverse record raised when device telemetry crosses a rule you've defined — the small subset of device messages that someone actually needs to act on. Field Service gives alerts a business process flow that walks from alert, to case, to work order, so a dispatcher can decide whether to fix it remotely or send someone.

Key facts

Alerts live in msdyn_iotalert and appear under Assets > IoT Alerts in the Service area.
With the IoT Hub deployment, the alert condition is a Stream Analytics query — a temperature above a threshold, for example. Dataverse receives the result; it does not evaluate the rule.
The raw device message is stored on the alert in the Alert Data field as JSON. That's your evidence trail and, in practice, the thing technicians actually want to see.
Autoparenting groups similar alerts from the same device raised within a five-minute window under a parent alert. The list shows a hierarchy icon on grouped records.
What "similar" means is configurable under Settings > IoT > Alert Aggregation Rules — you pick the fields used to match alerts, such as device and alert type.
The five-minute debounce is a property of the IoT - Parent Iot Alerts workflow in the solution. Change it there, or disable the workflow to turn grouping off entirely.
The out-of-the-box flow is alert to case to work order, not alert straight to work order. The case stage exists so someone can try to resolve remotely before committing a truck.
The work order carries a reference back to the alert, so the technician can see what tripped and when.
IoT alert suggestions was deprecated on 3 September 2024 and stopped being available after November 2024. Don't design around it.
Alerts are ordinary Dataverse rows. Nothing stops you automating the conversion with Power Automate or a plugin, and on most real deployments you will.

When to use / skip

If you've stood up any IoT integration at all, you're using alerts — this is the landing point. The judgment call is not whether to use alerts, it's how much automation to put behind them.

Full automation, where an alert silently becomes a scheduled work order, is only sensible once you trust the rules. On a new deployment you don't. Run the first few months with a human in the loop: alerts land, a dispatcher triages, conversion is a deliberate click. Then automate the alert types that have proved themselves. Clients who automate on day one end up with a scheduling board full of work orders for a sensor that was reporting badly, and they lose faith in the whole thing.

The reverse case is also real. If the client's devices only ever raise one alert type and it always means "send an engineer", the case stage is pure friction. Strip it out with a custom flow rather than making dispatchers click through a business process flow that adds nothing.

Configuration decisions

Which telemetry conditions justify an alert at all, and which are just data. Getting this wrong is the single biggest cause of a failed Connected Field Service rollout.
Aggregation fields and the debounce window: how narrowly you match alerts determines whether you get one parent record per fault or a hundred siblings.
Whether to keep the case stage, automate it, or bypass it — and if you keep it, who owns the remote-resolution attempt.
How the alert resolves to a customer asset and account, since work order creation depends on that link being right.
Which alert types are eligible for fully automatic work order creation, and which always need a human.
What happens to alerts nobody converts — an ageing rule, an auto-close, or an ever-growing list.

Gotchas

Autoparenting is on by default and it is a workflow, not a setting on a form. People spend an afternoon looking for a configuration screen that doesn't exist.
Disabling the parenting workflow to "see all the alerts" during testing and then forgetting to re-enable it is a classic. Production then drowns.
Aggregation groups alerts; it does not stop work orders. If your automation converts every alert including children, dedupe at the alert level has bought you nothing.
Alert Data is JSON in a text field. It is not searchable or reportable in any useful way without extracting the values you care about into real columns, and that extraction is your job.
The alert-to-case-to-work-order flow is a business process flow, so the security roles for dispatchers and resources need access to it. A dispatcher who can see alerts but not the process flow gets a screen that appears broken.
Anything written against IoT alert suggestions is dead. It went away after November 2024, so treat older blog posts and pre-2024 design documents with suspicion.

Consultant notes

Demo the alert record with real-looking JSON in Alert Data. Clients grasp the value immediately when they see the actual sensor payload attached to a work order.
Tell the client plainly that alert quality is their problem, not the platform's. Field Service will faithfully create a work order for every bad reading you send it.
Agree a triage owner before go-live. Alerts arriving in a queue nobody watches is the most common way these projects quietly die in month three.
Before go-live, test the noisy case: unplug a simulated device, or send a flapping sensor, and check what the aggregation rules actually produce. Tune the debounce against that, not against a tidy single-fault demo.
Push back on "we'll automate everything from day one". Offer a phased automation plan instead; it's an easier sell than it sounds once you explain the failure mode.

Worth revisiting if Microsoft reworks the alert business process flow, or adds a supported replacement for the retired alert suggestions.