If you go to Microsoft Learn (https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/integration-overview) right now and look up the official integration patterns page for finance and operations apps you will find a short, tidy list:
| Pattern | Documentation |
|---|---|
| Power Platform integration | Microsoft Power Platform integration with finance and operations apps |
| OData | Open Data Protocol (OData) |
| Batch data API | Recurring integrations Data management package REST API |
| Custom service | Custom service development |
| Consume external web services | Consume external web services |
| Excel integration | Office integration overview |
That is it. Six entries. Some sample scenarios.
What that page does not cover: Business Events. Electronic Reporting as an integration mechanism. Dual-write. Synapse Link. Fabric. BYOD. SFTP and file-based integration. Logic Apps as orchestration. In other words, most of what your project will actually use in production. Some of these overlap with the listed patterns (Dual-write touches Power Platform integration, Business Events can be consumed through Logic Apps, BYOD overlaps with the Data management API), but each deserves to be treated as its own mechanism because the design decisions, limits and failure modes are different.
OData: the one everyone reaches for and the one everyone misuses
OData is the default answer when someone says let’s integrate with F&O. It is rarely the right answer at scale.
OData is great for low volume, request-response, go fetch me this customer scenarios. It is poor for bulk operations, poor for high frequency writes and surprisingly poor for complex entities where you will spend a week figuring out why a nested POST returns a 400 with an unhelpful error.
Microsoft itself buries a useful hint in the docs: do not use OData for Power BI reports, use entity store instead. That note is doing a lot of work. The unstated principle is that OData is for transactional, real time, low volume lookups. Everything else has a better pattern.
Where OData shines:
- A Logic App that needs to look up a vendor by VAT number
- A lightweight portal that reads open invoices
- Anything where you need synchronous, is this record real validation
Where OData will hurt you:
- Loading hundreds of thousands of records from a legacy system
- Any integration where throughput matters more than latency
- Anything that needs to survive a sandbox refresh without re-authentication ceremony
The biggest mistake I see: the entire integration gets built on OData because the proof of concept worked with 50 records. Then go live hits, volumes are 1000x what tested, throttling kicks in, retry storms cascade and someone is asking why the integration platform is on fire.
If you hit 429s in production, that is not a problem to solve with more retries. That is a sign you picked the wrong pattern.
Batch data API and DMF: the one that actually scales
Microsoft’s own guidance is that if your integration moves more than a few hundred thousand records, you should be using the batch data API, not OData. They are right. The Data Management Framework underneath, with its composite entities and staging tables, is the proper answer for bulk. It is not glamorous, it is not modern, but it works.
DMF is what you should use for:
- Initial data migration
- Recurring bulk imports from upstream systems
- Recurring exports to downstream systems
- Anything north of a few thousand records
The catch: DMF is unforgiving about data quality. Staging tables will swallow your bad rows, post will half succeed and you will spend three hours figuring out why GeneralJournalAccountEntry has orphans. Build validation upstream, not in F&O.
Also DMF performance tuning is a real skill. Parallel processing settings, entity execution parameters, batch group configuration, incremental push instead of full pushes, skip staging where the entity supports it. The defaults are conservative. Tune them or accept that your nightly import takes 12 hours.
Most projects should be using DMF for a large share of what they currently do in OData. They do not, because OData feels modern and DMF feels like 2012. The right tool does not care about your aesthetics.
Custom services: when OData is not enough
Custom services are how you expose business logic from F&O over SOAP or REST without bending an OData entity into something it was never meant to be.
This is the right pattern when:
- You need to run real business logic on demand, not just CRUD an entity (validate a complex business rule, return a derived value that lives in code rather than data)
- The shape of the request or response does not match any standard entity
- You want a stable contract with the external system that does not change every time someone adds a field to a table
Custom services are synchronous like OData. They have the same throttling and authentication story. They are not a workaround for bulk performance problems. They are a workaround for the fact that OData entities are awkward when what you actually need is a function call.
The downside: you are writing code that needs to be maintained, deployed and versioned alongside the rest of your customizations. For a one off lookup this is overkill. For a stable integration point that other teams will call for years, it is the right call.
Power Platform integration: the connector you forget exists
Microsoft lists Power Platform integration as a pattern and they are right to. F&O has first party connectors for Power Automate, Power Apps and Logic Apps that hide most of the OData and Business Events plumbing behind clicks.
This is the right pattern when:
- A business user, not a developer, owns the integration
- The workflow is event driven and low volume
- You want something working in an afternoon, not a sprint
The downside: connector based integrations are easy to start and easy to forget. They run under someone’s personal license, they break when that person leaves the company and they are invisible to whoever inherits the environment. If you build anything important on a connector, put it on a service account, document it and put the flow in a managed solution.
Consume external web services: F&O as the client, not the server
Most integration content assumes external systems calling into F&O. But F&O can also call out. This is what consume external web services covers: using code to invoke a SOAP or REST endpoint somewhere else and process the response.
This is the right pattern when:
- A posting routine needs to call an external service inline (tax validation, address verification, credit check, exchange rate lookup)
- The business logic genuinely belongs in F&O and the external call is one step inside it
- You have no good place to put orchestration outside F&O
Excel integration: the pattern your users will like
Microsoft includes Office integration in the official list and it deserves to be there. The Open in Excel feature lets users pull data from F&O entities into Excel, edit it and push it back. The Excel add-in handles the OData calls behind the scenes.
This is the right pattern when:
- A power user needs to do bulk edits on master data that does not justify building a real integration (vendors, customers, products, prices)
- The data already lives in an entity and the user already lives in Excel
- You want to give the business a self service tool without writing anything
The downside which every developer has lived through: users will use this for things you did not expect. They will edit thousands of records, hit save and create a problem. Train them, restrict the entities they can open in Excel and audit what changes.
That covers the six patterns Microsoft puts on the official page. Now the ones it leaves off.
Business Events: the pattern nobody uses and almost everyone should
Business Events is the most underrated integration mechanism in F&O. It is also, notably, absent from Microsoft’s official integration patterns page. You have to find it on its own page, in a different part of the docs and figure out for yourself that it belongs in the integration conversation.
Business Events is event driven, push based, lightweight and it has been generally available for years while developers build polling integrations that hammer OData every five minutes asking anything new yet.
Business Events are right when:
- Something downstream needs to know when a thing happens in F&O (PO confirmed, invoice posted, payment journal posted)
- You want push, not pull
- You can tolerate eventually rather than instantly
Why does nobody use this? First, it requires changing how people think about integration: from I will go ask F&O to F&O will tell me. Second, debugging is harder than it looks. When a Business Event does not fire, there is no error in the integration platform because nothing was called. You have to know to check the F&O side, the endpoint configuration and the event payload separately. Polling integrations fail loudly. If your Logic App asks F&O every five minutes whether anything changed, you can see the runs, you can see the failures, you can rerun them. Event driven ones fail silently.
Logic Apps: the glue not the integration
Logic Apps is not an integration pattern. Microsoft does not list it on the patterns page for a reason: it is not an F&O API. It is an orchestrator that calls F&O APIs.
This distinction matters because too many integration architectures are a Logic App with twenty actions, no error handling, no idempotency, no retry strategy and a single point of failure that runs in someone’s personal Azure subscription.
Logic Apps is great as a transport and orchestration layer. It is poor as a system of record for integration state. Use it to move data, transform lightly, route to the right endpoint, handle the obvious errors. Do not use it to:
- Maintain integration state across multiple runs
- Implement complex business logic that should live in F&O
- Replace a proper ETL tool when you actually need ETL
Things you should do:
- Use Service Bus or Storage Queues for anything resembling reliable delivery
- Separate the trigger workflow from the processing workflow, because debugging a 50-action Logic App is psychological warfare
SFTP and file based integration: not dead, just unfashionable
Every six months SFTP gets declared dead. Every six months the bank still does not have an API, the government tax authority absolutely does not have an API and SFTP keeps doing what it has always done. It is going to be here when we are all dead.
File based integration is correct for:
- Anything involving banks (payment files, statements, MT940…)
- Government filings in most of Europe
- Partner integrations
The pattern: Logic App triggered by blob arrival or schedule, pulls from SFTP, drops in Azure Storage, triggers DMF import via the package API or feeds Electronic Reporting. Or the reverse: ER generates the file, blob trigger picks it up, Logic App sends to SFTP, archives, notifies.
Electronic Reporting: is not just for reports anymore
ER is officially a reporting and format generation tool. That is also why it does not appear on the integration patterns page. In practice, it has quietly become one of the most important integration mechanisms in F&O, especially in Europe where every country has its own tax filing format, payment format and statutory report.
ER is what you use when:
- You need to produce a specific file format the bank or government will reject if a single character is wrong
- The format will change and you do not want to redeploy code each time
ER is configuration, not code. Microsoft built it so that functional consultants could own it. In practice, the report designer is complex enough that you usually end up with a developer doing the work anyway or a functional consultant who slowly turned into a developer along the way. Not code does not mean not technical.
The honest downside: debugging ER is its own discipline. Get value returns empty string in the debugger and you have no idea why. I have spent more hours staring at ER format mappings than I am willing to admit publicly.
But the alternative is custom X++ code that nobody can maintain, so ER wins.
Dual-write, Synapse Link and Fabric: the moving target
I am going to be careful here because Microsoft’s story on F&O to Dataverse and F&O to analytics has changed every 6 months for several years. None of these appear on the integration patterns page either, because Microsoft treats them as separate product surfaces. They are integration mechanisms whether the documentation admits it or not.
As of right now:
- Dual-write is for keeping F&O and Dataverse in sync at runtime. It works. The mappings can be customized, but within limits. If your Dynamics 365 footprint includes both F&O and CRM, you probably need it. If you do not, you probably do not.
- Export to Data Lake is retired. Microsoft pulled the plug in March 2025. If your project still relies on it, that is the priority migration.
- Azure Synapse Link for Dataverse is the current supported path for replicating F&O data into Azure for analytics.
- Link to Microsoft Fabric is the newer option, integrated with Fabric Lakehouse. Microsoft is steering customers here when Fabric is part of the picture.
- BYOD still works and has no formal deprecation notice as of this writing. But Microsoft has not invested in it for years and every Microsoft message about analytics for F&O points to Fabric or Synapse Link.
My advice: do not architect new long term analytics solutions on BYOD in 2026. Plan for Synapse Link or Fabric depending on where the rest of your stack lives and accept that the recommended path may shift again.
So what should you actually do?
A defensible integration architecture for a typical F&O project in 2026 looks like this:
- Bulk in/out: Batch data API and DMF, orchestrated by Logic Apps or Data Factory
- Real-time lookups: OData or custom services, sparingly, with proper throttling handling
- Event notifications out of F&O: Business Events to Service Bus, Event Grid, or Logic Apps
- Bank and government files: ER for format generation and parsing, Logic Apps and SFTP for transport
- Analytics: Synapse Link or Link to Fabric, depending on the rest of your data stack
- F&O and CRM sync: Dual-write, if you have both
The pattern that should not exist but somehow always does:
- Everything through OData
- A Logic App with 47 actions
- One scheduled DMF job nobody can remember
- A BYOD database that has not been updated for years
The best F&O integration architecture is the one where each pattern is used for what it is good at, where state lives in the right place, where errors are handled at the right layer and where the person on call can figure out what broke.
Dynamics Lab 
Leave a comment