# MES integration with D365 Supply Chain: Azure middleware pattern

> Source: <https://dev.to/sapotacorp/mes-integration-with-d365-supply-chain-azure-middleware-pattern-4698>
> Published: 2026-05-24 02:52:14+00:00

Manufacturers running Dynamics 365 Supply Chain Management almost always also run a dedicated Manufacturing Execution System (MES) on the shop floor. Production order updates, inventory movements, quality tests, and traceability data flow between them continuously. The integration has to be low-latency (shop floor runs on seconds, not hours), high-throughput (hundreds of events per minute at peak), and reliable (lost messages mean lost traceability).
Three integration patterns come up in evaluations. Two have documented failure modes.
Nightly batch jobs via Data Management Framework. Designed for bulk data movement, not real-time signaling. Production orders complete hours before D365 knows about it. Real-time inventory view is always lagging. Traceability data arrives after the batches have shipped.
Custom OData polling with a loop that queries MES every few seconds. Introduces polling overhead for no latency benefit, and MES systems aren't typically designed to handle heavy poll loads. Also creates a custom code dependency that needs maintenance.
Database-level triggers on the MES database pushing directly to F&O's database. Breaks supportability completely. D365 F&O is a managed platform - direct database writes aren't supported, aren't upgrade-safe, and will break the next time Microsoft changes schema. Also creates a security nightmare (MES has privileged write access to F&O's database?).
The only answer that fits the requirements is Azure middleware between the two systems.
Logic Apps or Service Bus as middleware between MES and D365, with F&O Business Events on the D365 side.
What each piece does:
Azure Service Bus for the guaranteed-delivery, ordered messaging. Production-order status updates, inventory moves, quality-test results flow through Service Bus queues with FIFO ordering per production order.
Azure Logic Apps for the orchestration where branching and transformation happen. A pick-complete event from MES fires a Logic App that transforms the payload, updates inventory in D365, and triggers the next production-flow message back to MES.
F&O Business Events for the D365-side publishing. When a production order is created, released, or completed in F&O, a business event fires to Service Bus or Event Grid. MES subscribers pick it up.
Custom Services on F&O for the inbound - when MES has a state change D365 needs to record, the Logic App (or Function) calls a custom service endpoint on F&O. Custom services are designed for low-latency targeted writes, unlike data entities which are bulk-optimized.
Traceability is specific in manufacturing - regulators and customers need to know which raw materials went into which finished-goods batch. D365's batch tracking combines with MES's shop-floor batch recording to produce the full lineage. The integration ensures:
The integration isn't just about moving data - it's about keeping the correlation intact under all failure modes.
At manufacturing scale (large plants with multiple lines, each firing events per minute), throughput planning matters:
Manufacturing can't afford lost messages. The architecture carries:
Flows in each direction have different shapes:
MES → D365 (updates ERP from shop floor):
D365 → MES (issues work to shop floor):
Bidirectional correlation:
Not everything is Logic Apps. Sometimes:
Each has a clear use case. Reach for them when the declarative tool hits a limit, not as default.
A working MES-to-D365 integration has:
The pattern is architect-grade because manufacturing systems won't tolerate the simpler options. Azure middleware is the supported, scalable, maintainable middle.