INTEGRATION · MICROSOFT DYNAMICS 365

Dynamics 365 integration with RTLS and RFID.

Locating data is worth very little until it changes what the ERP believes. This is how RTLS, RFID and IoT connect to Dynamics 365 Supply Chain Management, which integration surface to use for which job, and the design decisions that are expensive to reverse.

Book a 30-minute scoping call

Start with the licence plate

The single most useful thing to understand about D365 warehouse management is the licence plate. It is the identifier the system already uses for a handling unit — a pallet, a container, a carton — and it is the natural hook for a physical tag.

A frequent failure mode for RFID programmes inside D365 is a parallel identity. The tag gets its own number, a mapping table appears, and from then on every discrepancy is an argument about which system is right. Encoding the licence plate into the tag, or registering the tag against it at the point of creation, avoids an entire category of problem.

Where licence plates are not used — serialised parts, tools, returnable assets — the question becomes which existing D365 entity carries identity, and the answer is worth settling before any hardware is specified.

The integration surfaces, and what each is for

D365 offers several ways in. Choosing the wrong one is a common reason a locating project works in a pilot and falls over in production.

Surface	Use it for	Not for
Business events	D365 telling the outside world something happened — work created, shipment confirmed	High-frequency telemetry
OData and custom services	Reads and transactional writes from an integration layer	Bulk loads; continuous streams
Data management framework	Scheduled batch in and out	Anything that needs to be timely
Dual-write / Dataverse	Keeping master data aligned with the Power Platform	Sensor data
Azure IoT Hub or Event Hubs	The location and sensor stream itself	Talking directly to D365
Fabric / Data Lake	Analytics, dwell, utilisation, history	Driving operational transactions

The pattern that holds up: telemetry lands in Azure, is reduced to events that matter, and only those events touch D365. A position update every second is not a business event. A pallet crossing from staging to outbound is.

Do not stream positions into the ERP

It is worth stating plainly because it is proposed surprisingly often. D365 is a transactional system with a batch framework and API limits. It is not a time-series store.

Six hundred tags reporting at 1 Hz is about 52 million events a day (600 × 86,400 seconds). The correct architecture keeps that stream outside the ERP entirely and sends D365 only state changes: arrivals, departures, completions, exceptions. Everything else belongs in a lake for analysis.

This is also what protects the upgrade path. The more your locating design depends on customisations inside D365, the more painful every platform update becomes.

Where locating actually changes D365 behaviour

Receiving. A read at the dock can create or confirm the licence plate and trigger put-away work, replacing a manual scan rather than adding a step alongside one.

Put-away and location accuracy. D365 knows where it directed stock to go. Locating tells you where it actually went. Reconciling those two is often the fastest measurable win.

Cycle counting. RFID changes counting from a scheduled event into a continuous background process, which changes how counting work is configured rather than simply speeding it up.

Work in progress. Zone transitions become genuine progress signals instead of operators confirming steps after the fact.

Yard and dock. Trailer and container position is generally absent from the ERP altogether, which is why it is often the easiest place to show value.

Warehouse Management only, and greenfield programmes

D365 Warehouse Management can be run against a third-party ERP using Microsoft’s Warehouse management only mode. If that is the shape of your estate, integration has two hops rather than one, and the identity question becomes more important, not less.

If D365 is not live yet, the sequencing question matters more than the technology. A locating design built around a warehouse process that is itself about to change will be rebuilt. The usual answer is to specify the data model now, fix the identity strategy, and defer the deployment decisions that depend on the new process until it is stable.

The questions worth settling early

Does the tag carry the licence plate, or map to it?
Which events are genuine business events, and which are telemetry?
Who owns the integration layer — your ERP partner, the locating vendor, or you?
Does location data ever write back to D365, or only inform?
What happens when they disagree, and which one is authoritative?

That last question decides more than any technology choice. Settling it in design saves rework in testing.

How we help

We do not implement Dynamics 365 and we do not resell locating hardware, so we have no reason to push the integration in either direction. We specify what the data model needs to be, which events matter, and what the locating vendor and the ERP partner each have to deliver — before either of them quotes.

Sources

Standards and vendor facts on this page come from the public sources below, checked on 25 September 2026. Vendor statements are reported as the vendor’s own claims.

Last updated: 25 September 2026