RFID and IoT Integration with Microsoft Dynamics 365
Which Dynamics 365 product you are integrating with decides everything else. A practical guide to the endpoints, the warehouse objects a tag read has to become, and the decisions to settle before anyone writes code.
"We integrate with Dynamics 365" is not a specification. Dynamics 365 is a family of applications with separate lineages, separate data models and separate integration surfaces, and the work involved in getting a tag read into one of them tells you almost nothing about the work involved in getting it into another. Before anything else is decided, establish which product is actually in front of you.
Start with the product you are actually running
Three things commonly travel under the Dynamics 365 name in a warehouse or plant conversation.
- Dynamics 365 Finance and Dynamics 365 Supply Chain Management: the applications that descend from AX, often referred to together as the finance and operations apps. Supply Chain Management is where the Warehouse Management module lives, and with it license plates, warehouse work, work templates, location directives and the warehouse mobile app. This is the richest environment to integrate into and the one with the most existing structure to respect.
- Dynamics 365 Business Central: the NAV lineage, aimed at smaller operations. It has its own warehouse functionality, with bins, warehouse receipts and shipments, item journals and item tracking for lots and serials. The concepts rhyme with Supply Chain Management but the objects and the APIs are different.
- Dataverse and the Power Platform, sitting alongside either, with dual-write keeping finance and operations data in step with Dataverse tables. This is worth knowing about because it is often mistaken for an integration bus. It is a synchronisation mechanism between Microsoft applications, not a place to land raw device traffic.
The same physical event, a tagged pallet crossing a dock door, lands in a completely different object in each. Getting this question answered in the first discovery conversation saves redesigning the integration in the third.
The integration surfaces Dynamics 365 gives you
For the finance and operations apps, the realistic options are these.
| Surface | Suited to | Worth knowing |
|---|---|---|
| OData endpoints | Reading and writing individual records against data entities | Subject to throttling; a burst of single calls is exactly the pattern that trips it |
| Custom service endpoints | Operations that need business logic the standard entities do not express | Implemented in X++ inside the application, so they carry a development and deployment cycle |
| Data Management Framework package API | Bulk and batch imports: a full cycle count, a day of backlogged events | Asynchronous and package-based; you submit, then poll for execution status |
| Business events | Outbound notification when something happens inside the ERP | Push rather than poll, delivered to endpoints such as Azure Service Bus, Event Grid, Azure Functions or an HTTPS endpoint |
| Dual-write to Dataverse | Keeping finance and operations data aligned with Dataverse | A synchronisation feature between Microsoft applications, not a general-purpose integration layer |
Business Central presents a different set.
| Surface | Suited to |
|---|---|
| The standard REST API | Common entities, already exposed and versioned |
| Custom API pages and API queries, written in AL | Your own entities, or a shape the standard API does not offer |
| OData and SOAP web services published from pages and codeunits | Exposing logic that already exists in the application |
| Webhook subscriptions | Outbound change notification without polling |
| An AL extension | Logic that genuinely has to execute inside Business Central |
Authentication across the modern stack runs through Microsoft Entra ID using OAuth 2.0, typically with a registered application and a service-to-service arrangement rather than a named human account. Older guidance describing basic authentication no longer reflects how the online products work. Which of these surfaces is enabled, and under what licence, depends on the environment. Confirm it against the tenant rather than against a blog post.
What a tag read actually has to become
This is the part that separates an integration operations trusts from one that quietly accumulates a reconciliation backlog. A reader produces an EPC and a timestamp. Dynamics needs a business transaction against an object it already understands.
In Supply Chain Management, the license plate is usually the right target. It exists precisely to identify a physical container, whether a pallet, a cage or a tote, and every warehouse process downstream already knows how to move one. Mapping a pallet-level tag to a license plate means the read participates in warehouse work, put-away and picking without inventing a parallel concept. From there the candidate destinations are the ones the module already provides: inventory counting journal lines for a cycle count, product receipt against a purchase order for inbound, warehouse work completion for a movement, item arrival journal entries for receiving.
In Business Central the equivalents are item journal lines, warehouse receipt and shipment lines, the physical inventory journal, and item tracking lines where lot or serial numbers are in play.
In both cases, one point deserves stating plainly because it is the single most common design error: an EPC is not an item number. It identifies a specific physical thing, not a product type. Something has to resolve one to the other: a mapping that says this tag is this license plate, holding this item, in this quantity. The first architectural decision worth arguing about is which system owns that mapping and how it is maintained when a pallet is rebuilt.
A reference architecture
- Readers publish reads to an edge service on the site network, not directly to the ERP.
- The edge filters. It deduplicates within a time window, applies read-zone rules, infers direction of travel where that matters, and discards tags that were merely nearby rather than moving.
- The edge resolves each surviving read from EPC to business identity: license plate, lot, serial, item.
- It composes the Dynamics transaction and selects the appropriate surface: a data entity call for a single movement, a Data Management Framework package for a bulk count.
- Every outbound transaction carries an idempotency key and is recorded in an outbox, so a retry after a timeout cannot post twice.
- Anything that cannot be resolved or accepted lands in an exception queue with enough context for a person to clear it, rather than being dropped or retried forever.
- Business events flow the other way for anything the floor needs to know: a released work order, a changed pick.
The shape of this matters more than the technology in it. The edge absorbs the noise and the ERP receives only decisions.
Decisions to settle before anyone writes code
- Which application, which version, and which environment tier the integration will be built and tested against.
- Who owns the mapping from tag to business object, and what maintains it when pallets are built and broken down.
- Whether a read is allowed to post a transaction unattended, or whether an operator must confirm it. This is a business control question, not a technical one.
- What happens when connectivity to Dynamics is lost for an hour. Buffer at the edge and replay, or stop the operation? Both are legitimate; only one can be the default.
- How number sequences behave under concurrent posting from an automated source.
- What the integration consumes in licensing terms, which is worth confirming against the licensing position rather than assuming.
Where these integrations usually go wrong
- One call per read. A dock-door sweep can produce hundreds of reads in seconds. Issuing an individual write for each is the fastest way to meet throttling, and throttling during a shipment is an operational incident, not a technical curiosity. Batch.
- No idempotency key. The network times out, the client retries, and a goods receipt is posted twice. The fix is cheap at design time and expensive afterwards.
- Filtering inside the ERP. Pushing raw reads into Dynamics and cleaning them up in X++ means every noisy read costs a transaction and every rule change costs a deployment.
- Posting against the item and losing the container. It works in a demonstration with one pallet and falls apart the first time two pallets of the same item are in the same aisle.
- Testing only with sandbox data volumes. Throughput problems do not appear at ten tags. Validate against realistic read rates before committing to a rollout.
How we scope a Dynamics 365 integration
We start with the physical workflow and the environment, not the endpoint. Which application and version, which warehouse configuration, which movements are in scope, what the site looks like in radio-frequency terms, and what the operation is expected to do when something does not read. Only then does the interface choice become obvious, and it usually turns out that the difficult part was never the API.
