F&O integration patterns. What Microsoft's documentation won't tell you

The developer documentation for Dynamics 365 Finance and Operations (F&O) on Microsoft Learn lists the integration patterns on one page, the integration overview. It names six, which are Power Platform integration, OData, the batch data API, custom services, external web services and Excel integration.

It does not mention business events, Electronic reporting (ER), Dual-write, virtual entities, Azure Synapse Link for Dataverse, Link to Microsoft Fabric, bring your own database (BYOD), files over SFTP or the Dynamics 365 ERP MCP server. Most projects run on several of them. The implementation guide on Learn has a longer table that adds ER and business events and gives each pattern a line of drawbacks.

Neither page says much about when not to use a pattern or about the limits you hit in practice. This post adds both for the six patterns on the list and for what the list leaves out. The short answer is the table under The pattern for each job.

The six patterns on Microsoft’s list

OData

OData is the pattern everyone reaches for first and the one that is misused most. It is a synchronous REST endpoint over the public data entities.

At scale it is rarely the right answer. I use it for low-volume calls that need an answer at once, such as a vendor lookup by VAT number or a portal that reads open invoices.

I do not use it to load hundreds of thousands of records, for frequent writes or for Power BI reports. It is also poor for complex entities, where you can spend a week on a nested POST that returns a 400 response.

The biggest mistake I see is an entire integration built on OData because the proof of concept worked with 50 records. After go-live the volumes are a thousand times higher, F&O starts to throttle and the retries pile up.

A 429 response tells the client to wait for the time in the Retry-After header and then try again. The limits follow the load on the web servers, so the cause can be another integration. Give the integrations that matter a higher priority under System administration > Setup > Throttling priority mapping. If one integration still keeps collecting 429 responses, more retries will not fix it. I take it as a sign of the wrong pattern and move it to the data management framework (DMF), which is currently exempt from the limits.

Batch data API and DMF

This is the pattern that scales. It is not modern but it works. Behind it are DMF and two APIs. The recurring integrations API takes files and data packages and the Data management package REST API takes only data packages.

I use it for data migration and for recurring bulk imports and exports. Microsoft’s rule of thumb is to use it above a few hundred thousand records. That is right for bulk, but I draw the line much lower, at a few thousand records in one run.

DMF is unforgiving about data quality. An import can succeed for part of a file and leave the bad rows in staging. The API does not call back, so the caller has to ask for the status of every run. Validate the data before it reaches F&O.

Tuning is a skill of its own. I find the defaults conservative. The settings are in part 2 of my data entities series. Tune them or accept that the nightly import takes 12 hours.

Most projects should move a large share of their OData work to DMF. They do not, because OData feels modern and DMF feels like 2012.

Custom services

A custom service is the answer when an OData entity is not enough. It exposes X++ business logic on a SOAP and a JSON endpoint. I use one when logic has to run on demand, when the request or the response fits no standard entity or when I want to define and version the contract myself.

Custom services are synchronous and throttled like OData, so they do not solve a bulk performance problem. They solve the case where you need a function call and an entity is the wrong shape for it.

The cost is code that you maintain, deploy and version. For a one-off lookup that is too much. For a stable integration point that other teams will call for years it is the right choice.

Power Platform integration

The name does not mean the Power Automate connector. It means the link between one F&O environment and one Dataverse environment. These features run on that link:

Virtual entities. Dataverse reads and writes F&O data live, without a copy.
Dual-write. The data is copied and both copies are kept in sync.
Business events and data events. They are described under Business events.

I compare the first two in Dual-write vs. virtual entities and describe the setup of Dual-write and virtual entities.

The Power Automate connector is a separate thing. It is called Fin & Ops Apps (Dynamics 365) and can connect to any F&O environment in the tenant, not only to the linked one. I use it when the integration belongs to a business user, the volume is low and it has to work after an afternoon and not after a sprint.

A flow on the connector is easy to start and easy to forget. It runs under the personal account of whoever built it, breaks when that person leaves and is invisible to whoever inherits the environment. For anything important use a dedicated user account, document the flow and put it in a managed solution. The connection dialog offers a service principal, but this connector does not support it.

External web services

Here F&O is the client. X++ code calls another system and processes the response. I use it when the logic belongs in F&O and the external call is one step inside it, such as a tax validation or a credit check in a posting routine.

The cost is a dependency on a system you do not control. The outbound IP address is not fixed, so an allow list on the other side has to hold the whole published range for your Azure region. Keep keys and passwords out of the X++ code and keep certificates in Azure Key Vault, which you set up under System administration > Setup > Key Vault parameters. Decide in advance what the posting does when the service is down.

Excel integration

This is the pattern your users will like. With Open in Excel a user pulls entity data into Excel, edits it and publishes the changes. The Excel add-in does it over OData.

I use it when a power user has to edit master data in bulk and the job does not justify an integration.

Every developer has lived through the downside. Users edit thousands of records, publish them and leave you with a problem. Train them, restrict the entities they can open in Excel and audit what changes.

What the list leaves out

Microsoft documents everything below, but the integration overview names none of it. Business events and Dual-write belong to its first entry, Power Platform integration. I still treat each of them as a pattern of its own, because its limits and the way it fails are different.

Business events

Business events are the most underrated integration mechanism in F&O. Few projects use them and I think most should. The system sends a small notification when a step in a business process is done, such as the posting of an invoice. Projects still poll OData every five minutes instead to ask whether anything is new.

I use them when another system has to know that something happened and a short delay is acceptable. For a plain change to a record there are data events, which entities enabled for OData can raise. They do not fire for an entity whose main data source is a view or for a change to a virtual field. The supported volume is 5,000 data events in five minutes and 50,000 in an hour per environment.

A business event is a notification and not a data export, so keep the payload small. The order of delivery is not guaranteed and an event can arrive twice, so each payload carries a control number for detecting duplicates.

I see two reasons why few projects use them. One is the change in thinking, because the other system no longer asks F&O for news. The other is debugging. A polling integration fails loudly. When a business event does not arrive, the integration platform shows no error because nothing was called. F&O retries three times by default and then keeps the event on the Errors tab of the Business events page, where you can resend it.

Azure Logic Apps

Azure Logic Apps is the glue between the patterns and not a pattern itself. Microsoft is right not to list it, because it is an orchestrator that calls F&O APIs.

I use it to move data, transform it lightly, route it and handle the obvious errors. I do not use it to keep integration state, to hold business logic that belongs in F&O or to replace an ETL tool.

Too many integration architectures are one logic app with twenty actions, no error handling, no idempotency and no retry strategy. It is a single point of failure in somebody’s personal Azure subscription. Use Azure Service Bus or Azure Queue Storage when a message must not be lost. Separate the trigger workflow from the processing workflow, because a long logic app is hard to debug.

Electronic reporting

ER is no longer only for reports. It has become one of the most important integration mechanisms in F&O, most of all in Europe, where every country has its own tax filing format, payment format and statutory report.

I use ER for a file that the bank or the government rejects if a single character is wrong. I also use it for a format that will change, because a change needs no code deployment.

ER is configuration and not code. Microsoft aims it at business users. In practice its designers are complex enough that the work ends up with a developer or with a functional consultant who has turned into one.

The downside is debugging. In the data source debugger Get value returns an empty string and nothing tells you why. I have spent more hours on ER mappings than I like to admit. The alternative is custom X++ that nobody can maintain, so I still choose ER.

SFTP and file-based integration

SFTP is declared dead every few months. The bank still has no API, a partner still wants a file on a server and the files keep coming.

I use files for banks (payment files and MT940 statements), for partners who can only exchange files and for government filings where the authority still takes files. Check first what Microsoft ships for your country, because Electronic messages in Finance can send a report to the web service of a tax authority.

Inbound, a logic app pulls the file from the SFTP server on a schedule. A file for a data entity goes to the recurring integrations API. A file in a format that ER parses goes into a SharePoint folder, where an ER import in batch reads one file per run.

Outbound, ER writes the file to a SharePoint folder through its Archive destination and a logic app carries it to the SFTP server. ER cannot write to a storage account of your choice without custom X++.

MCP for AI assistants

The Model Context Protocol (MCP) lets an AI assistant call tools outside of it. Microsoft’s Dynamics 365 ERP MCP server gives it tools that read and write data through data entities, work with forms and call X++ classes that a developer has written for that purpose. Every request runs as the signed-in user with that user’s F&O security roles.

It needs version 10.0.47 or newer on a Tier 2 or higher environment or on a unified developer environment. Outside Copilot Studio every tool call costs Copilot credits unless the user has a Finance Premium or Supply Chain Management Premium license.

Where it is available I see it as the right default. Where it is not, I use a server of my own over OData. I describe both in How to build your own D365 F&O MCP server.

Dual-write, Synapse Link and Fabric. The moving target

Microsoft’s guidance on getting F&O data into Dataverse and into analytics has changed several times in recent years. This is the state as of October 2026:

Dual-write. It keeps a copy of F&O records in sync for a Dataverse app such as Dynamics 365 Sales. A transaction from F&O carries at most 1,000 records and has to finish within two minutes, so it is not for bulk loads or analytics.
Export to Data Lake. Microsoft retired it on 1 November 2024 and stops the service for good on 30 November 2026, with no extensions. If your project still relies on it, that migration comes first.
Link to Microsoft Fabric. The data stays in storage that Dataverse manages and shows up in a Fabric lakehouse through shortcuts. You pay in Dataverse database capacity and need a Fabric capacity or a Power BI Premium license in the same Azure region as the Dataverse environment.
Azure Synapse Link for Dataverse. It exports F&O tables continuously to a storage account that you own. Its Delta Lake output, the one that needs your own Synapse workspace and Spark pool, is deprecated. From 15 October 2026 it is closed to new customers and existing customers have to move to CSV output or to Link to Fabric by December 2027. The other output for F&O tables is an incremental feed of CSV files, which needs only the storage account. Microsoft is also retiring the name and Power Apps now calls it Link to Data lake.
Bring your own database (BYOD). It still works and is not on the list of deprecated features, but Microsoft counts it among its legacy data integration services.

Link to Fabric and Synapse Link take F&O tables directly and neither needs Dual-write. A data entity can be exported only when it is enabled as a virtual entity and supports row version change tracking, which not every entity does.

My advice is the same as Microsoft’s this time. Start with Link to Fabric, choose Synapse Link only when the data must sit in your own storage account and build nothing new on BYOD. If you choose Synapse Link, plan for CSV files and not for Delta tables. The recommended path may change again.

The pattern for each job

This is what I would pick in a typical F&O project.

Job	Pattern
Bulk import and export	Batch data API and DMF, started by Azure Logic Apps or Azure Data Factory
Real-time lookups	OData or a custom service, used sparingly and with handling for the 429 response
Notifications out of F&O	Business events or data events to Azure Service Bus or Azure Event Grid
Bank and government files	ER for the format, Azure Logic Apps and SFTP for the transport, Electronic messages where the authority has a web service
Analytics and reporting	Link to Fabric, or Synapse Link when the data must sit in your own storage account
Dataverse app with its own copy of the data	Dual-write
Dataverse app that only shows or edits F&O data	Virtual entities
Flow owned by a business user	The connector in Power Automate, with a dedicated account and in a managed solution
Call from F&O to another system	X++ code that calls the external web service
Bulk edits by a power user	The Excel add-in, limited to the entities that user needs
AI assistant on F&O data	The Dynamics 365 ERP MCP server, or a server of your own over OData

Plan for the database refresh of a sandbox as well. It disables all users except the admin, holds all batch jobs, switches off change tracking and removes the Dual-write configuration and the event endpoints. Script the steps that switch each integration back on.

Final thoughts

I keep meeting the same setup that should not exist:

Everything through OData
One logic app with 47 actions
One scheduled DMF job that nobody remembers setting up
A BYOD database that has not been updated for years

For me the best F&O integration architecture uses each pattern for what it is good at. State lives in the right place, errors are handled at the right layer and the person on call can find out what broke.

Which of these patterns carries most of the load in your project? Let me know on LinkedIn or through the contact page.