.svg)
Understanding data entities in Dynamics 365 F&O
Before choosing an integration method, it helps to understand how Microsoft Dynamics 365 Finance & Operations (F&O) structures data for external exchange.
Rather than exposing its raw database tables directly to external systems, F&O uses data entities: simplified, structured representations of underlying data concepts like "Customer," "Vendor," or "Production order." Data entities apply the relevant business logic, validation rules, and security policies automatically, regardless of which integration method accesses them. All three primary patterns, OData, DMF, and Dual-write, interact with F&O through these data entities rather than directly with the database.
This matters in practice because it means external systems get a clean, governed view of ERP data rather than having to navigate complex normalized schemas. It also means that any integration built on data entities inherits the validation logic the ERP applies to that data, which reduces the risk of corrupt or inconsistent records entering the system.
OData: synchronous, real-time integration for low-volume flows
Open Data Protocol (OData) is the standard protocol for RESTful API communication in Dynamics 365 F&O. It operates synchronously: when an external system sends a request, it waits for F&O to process and return a response before continuing. This makes OData the right choice for scenarios where immediate confirmation matters and data volumes are low.
When manufacturers use OData
- PLM integrations: Creating a new product master or updating a specific Bill of Materials (BOM) version directly from a PLM system, where the PLM needs to confirm the record was accepted before proceeding.
- Logistics and shipping: Querying real-time freight rates or updating a shipment status when a package leaves the loading dock.
- Lightweight MES signals: Sending a real-time notification to F&O that a machine has completed a production step and consumed a defined quantity of raw materials.
Where OData breaks down
Dynamics 365 F&O applies strict throttling limits to OData to protect system performance. If an external system, such as a high-volume WMS or an aggressive analytics tool, sends too many rapid requests, F&O will throttle or reject them. This can result in timed-out requests and integration failures at exactly the moments when operational systems need data most.
OData should be reserved strictly for low-volume, high-urgency transactional data. Using it for bulk operations is one of the most common sources of Dynamics 365 integration instability in manufacturing environments.
DMF: asynchronous batch processing for high-volume data
The Data Management Framework (DMF), also referred to as DIXF in earlier versions of Dynamics 365, handles the opposite scenario: large data volumes that do not require an immediate response. Rather than processing requests synchronously, DMF accepts files in formats like XML, CSV, or JSON via a storage queue and processes them on a scheduled basis, without competing with live ERP operations for system resources.
When manufacturers use DMF
- WMS integration: Processing end-of-shift inventory journals, bulk picking routes, or large cycle count adjustments from a third-party warehouse system.
- Procurement updates: Importing vendor catalogs or updating thousands of purchase order delivery dates from a supplier portal simultaneously.
- Data warehousing and analytics: Exporting large datasets to a Bring Your Own Database (BYOD) environment or Azure Data Lake, allowing business intelligence tools to run complex queries without impacting live ERP performance.
The trade-off to understand
DMF introduces latency. Because it is asynchronous, the receiving system does not get an immediate confirmation that the data was accepted. For operations where timing is not critical and data volumes are high, this trade-off is clearly worth making. For anything requiring real-time feedback, DMF is not the right tool.
Dual-write: near real-time synchronization within Microsoft ecosystem
Dual-write is Microsoft's native infrastructure for bidirectional, near real-time synchronization between Dynamics 365 F&O and Microsoft Dataverse, which is the underlying database for Dynamics 365 Customer Engagement applications including Sales, Field Service, and Customer Service.
When Dual-write is configured, a data change in F&O triggers a corresponding update in Dataverse almost immediately, and vice versa. It is the right tool when a manufacturer needs master data to stay aligned across Microsoft applications without manual synchronization steps.
When manufacturers use Dual-write
A sales representative creates a new customer account in Dynamics 365 Sales. Dual-write propagates that customer record to F&O automatically. Product catalogs, pricing structures, and customer records stay consistent across the Microsoft ecosystem without anyone manually re-entering data between systems.
Where Dual-write has limits
Because Dual-write operates synchronously across two separate databases, it introduces performance overhead. If one system is temporarily unavailable, the transaction can fail in both. This makes it well-suited for master data alignment, customer records, product catalogs, pricing, but not for high-volume transactional data like thousands of individual inventory movements or raw telemetry from shop floor sensors, where DMF or OData is the more appropriate choice.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
