How to integrate with Dynamics 365 for Finance and Operations

Revised in October 2025

In this post, I’ll provide an up-to-date overview of the various integration options available in Dynamics 365 Finance and Operations. We’ll explore each integration method in detail—covering how they work, their strengths and weaknesses, and how they compare to one another. I’ll also share practical insights and lessons learned from my own hands-on experience implementing these solutions.

OData

OData is an open-source protocol that serves and consumes interoperable data using common query operations with RESTful APIs. D365 F&O exposes all its public data entities as OData endpoints, which can then be accessed using the following URI format :

https://<d365fourl>/data/<dataentity>

OData provides a quick and codeless data integration with its featured query options and CRUD operations. You can use its open standard query string language to query your data and do data manipulations using standard OData CRUD commands, all using just simple and open standard REST calls. There is even support for bulk operations like bulk insert and bulk update. With the OData actions feature, you can create and run custom methods within OData entities, manipulating data or running custom program logic.

You can definitely use OData for your own integration projects by building a REST client with any REST-enabled tool or programming language, but there are also many OData-ready software available today, and these can be directly connected to D365 F&O OData endpoints. Also, many F&O standard integration tools, like logic apps connector, Dual-Write, MCP server, and Data Factory connector use OData under the hood to perform the integration with F&O.

Although it looks like the optimum way of data integration with D365 F&O, there are some drawbacks involved. OData query and operation execution times are quite slow, and data reading may take ages if you try to retrieve a large entity. OData is mainly designed for simple CRUD operations and simpler queries. If you need to execute complex queries, like complex joins and lookups, for example, you may start to hit its limits.

There is also the throttling feature of D365 F&O that throttles calls to OData endpoints by giving priorities to them, to avoid system lockdowns that might be caused by frequent OData calls. You can read more about it from the link below :

https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/priority-based-throttling

Remember, you can also use OData endpoints in Azure API Manager, just like custom services and other F&O endpoints.

More info: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/odata

Custom Services

This is by far the most flexible and customizable way to integrate with D365 F&O amongst standard integration tools. Custom services are custom REST API endpoints that are created with standard D365 F&O X++ code. They can be used for both data-based and operation-based integrations. Flexibility is great since everything is created with the plain X++ programming language, the limit being just your imagination.

AIF services used in Dynamics AX are now upgraded to custom services in F&O, and they are automatically published into SOAP and JSON REST endpoints when deployed. However, management and monitoring tools used for old AX AIF services have now disappeared, leaving just naked, non-configurable service endpoints.

When you deploy a custom service, the following endpoints are created, and you can call them remotely using standard AAD OAuth authorization and SOAP/REST HTTP calls:

SOAP:

https://<d365fourl>/soap/services/<servicename>?wsdl

JSON:

https://<d365fourl>/api/services/<servicegroupname>/<servicename>/<operation_name>

Data integration in custom services is done via data contracts, which are then converted to XML or JSON depending on the endpoint. Performance of doing so is quite fast, compared to other data integration options, since everything is handled with low-level .NET commands under the hood. You can, in theory, transfer large amounts of data this way; however, I do not recommend doing so. With large data transfers, you may hit some unforeseen limitations and timeout problems on the way, and also the throttling. But it is always possible to program any kind of paging or chunking mechanism in your service class to send small chunks of larger data to skip these limitations.

If you need an example, I have used a custom service in my previous Android integration blog post, and the X++ code of this service is available on my GitHub page:

https://github.com/sertanyaman/native-android-integration-example-for-dynamics-365fo/blob/master/AndroidTest.axpp

The throttling mechanism we mentioned in the OData topic also exists for the custom service endpoints. F&O throttles the calls if the server reaches a limit.

If you need to do management and monitoring of your custom service, or configure some custom authorization methods instead of AAD, there is a possibility to connect it with Azure API Manager and empower its monitoring and authoring abilities, as described in my other blog post :

More info: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/custom-services

DMF (Data management framework)

DMF allows you to import and export big data in D365 F&O using various source/target data files and services. This is the recommended way of data integration in D365 F&O if you need to transfer large amounts of data from other systems using legacy file formats and services. It supports bulk or incremental data import/export options with change tracking and data staging features.

Import and export projects are created using D365 F&O standard “data entities”, which are normalized views of D365 F&O data tables and can be added programmatically if necessary. There is a dedicated Data management workspace (above), which you can set up data import and export projects, import actual data, or see available data entities and check integration mappings in graphical schemas. However useful it is, I cannot tell you that the DMF UI is a user-friendly one. Some parts of the “advanced” and the “standard” views are confusing to users, even to developers. Also, field mapping and Unicode setup parts are confusing and do not always work as expected.

There is support for every old file format that was used by Dynamics AX before, and some new formats and SQL Server DB connection options are also available. But there is still no support for modern data transfer file formats like JSON, Parquet, Delta, ARRF, Avro, etc. Also, as package options, you can only use ZIP compression, and there is no support for GZIP, which is widely used for data transfer today. To transfer the data inside a file, CSV files are the recommended option. As you can see in the analysis below from luminousmen.com, a CSV file is quite an outdated file format and falls far behind on every aspect compared to modern data transfer file formats. Bulk data integration with modern formats is only possible today via the Azure Fabric (Synapse) links, which I will mention later.

https://luminousmen.com/post/big-data-file-formats

DMF has REST APIs and actions to import and export data from outside D365 F&O. You can find Azure Logic Apps actions under the “DataManagementDefinitionGroups” section of “F&O Execute action” logic app block:

You can find example code (and logic apps) for DMF data import and export operations in the Dynamics-AX-Integration GitHub page. However, using these API commands and actions is not as straightforward as you expect. For example for importing a CSV file, you need to create a ZIP file package containing the file you want to import and add fixed Manifest and Header XML files in it, then place it in a temporary container DMF provides for you, import it using another action and then use an infinite loop for checking if the import is completed successfully or not using the get status action, and then try to get the actual error checking various DMF actions..

There is currently no other straightforward method for import and export available if you would like to use the DMF API calls, other than using the recurring integrations option instead. It would be very nice to have one straightforward option, though, that receives the data file as input and consolidated error and log messages as output..

Another thing to mention is running import jobs in parallel. If you make two (synchronous) API calls in parallel, importing into the same data entity, you get errors and problems. But it is possible to execute such an action using async DMF API methods instead, or async processing in logic apps. Also, the table you need to export should not have any SQL-level locks on it, or you run into some nasty problems. So exporting in a timeframe that users do not use the system is recommended.

More info: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/data-entities-data-packages

Recurring integrations

Recurring integrations is a D365FO data integration platform based on DMF and data entities, providing automated data exchange possibilities between third-party data providers. Once set up, the Recurring Integration platform REST endpoints can be used by third-party integrators to import/export data from and to D365 F&O using simple REST calls.

The recurring integrations feature can be enabled from a single button click in a DMF project, and later can be managed/monitored from the F&O Data management workspace:

It creates a recurring integration with an activity ID. Recurring integrations REST endpoints are then used to push and pull data for the recurring integration, in an ordered or scheduled way. Below are the standard recurring integrations, REST endpoints, and their usage:

https://<base URL>/api/connector/enqueue/<activity ID>?entity=<entity name>
https://<base URL>/api/connector/dequeue/<activity ID>
https://<base URL>/api/connector/ack/<activity ID>

You can directly import a data file as well as a zipped DMF data package without issues, and a consistency check for empty or corrupt files also exists. After the operation, DMF API calls and methods can then be used to check the status of the import or get the execution errors.

Recurring integrations provide the simplest way to integrate using DMF data import and exports. However, these REST endpoints used for recurring integrations are fixed, and you cannot extend them anyhow for custom functionality.

More info: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/recurring-integrations

Business events

D365 F&O business events feature allows you to send notifications of FO business events to Azure event handlers and trigger-based workflow providers. It comes with many out-of-the-box FO business events, plus it provides you with the ability to create new ones with X++ programming. Business events can be activated and used from the business event catalog form in D365 F&O:

You can send notifications from these events to Azure endpoints like Service Bus, Event Hub, Event Grid, and Logic Apps (or Power Automate), also to custom HTTPS endpoints using standard HTTP methods. It is also possible to subscribe to a business event directly from Logic Apps or Power Automate using the “When a business event occurs” trigger, as shown below:

It is also possible to attach small amounts of data to the notifications using the message payload; however, I would advise you to be really careful with that since attaching large amounts of data to your payload will not only create problems, it will also ruin the lightweight operation expected from an eventing platform.

If you need more information, I have a complete blog post about business events, describing also how to create a new event using X++: https://devblog.sertanyaman.com/2019/05/23/how-to-integrate-d365fo-with-microsoft-flow-using-the-new-business-events/

More info: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/business-events/home-page

Data events

Data events resemble business events and are triggered per CRUD operations performed on a data entity. They can also be activated and configured from the business event catalog form:

Unlike business events, data events are closely linked to Power Platform and require D365 F&O and Power Platform linking to be active in the environment where they need to be used. Then, triggered events can be published to endpoints set up in the BE catalog, or can be consumed by the Power Automate triggers for the created virtual entity:

There are limits in F&O on how many data events can be triggered per hour, so they are not quite suitable for entities that receive bulk updates, like products.

More info: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/business-events/data-events

Dual-write

Dual-write provides a near-real-time, tightly coupled, and synchronous-asyncronous data transfer between D365 F&O and Dataverse tables. Dataverse sits at the heart of Microsoft Power Platform and is used by many Microsoft Dynamics 365 applications (like CE, Sales, Field Service, Marketing, and Project Service Automation). Therefore, Dual-write makes it possible to integrate D365 F&O with the rest of the Dynamics 365 family.

Any data written to D365 F&O dual-write mapped data entities is written directly into its Dataverse mapped table in near real-time. Data validations and business logic are executed simultaneously on both sides and reflected to the user, showing messages and errors from both platforms. Recently also an asynchronous mode is added, eliminating the waiting time for users caused by its real-time data synchronization. Real-time data synchronization process has “Running” and “Paused” mode options, and can cache write operations in offline or paused mode to be executed afterward.

At the time of writing, a dual write setup can be done via LCS, the Power Platform admin center, and from the Data Management module section below. The details of the setup can be found here: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/connection-setup

Once set up and enabled, a health check is done for the linking, and you can do an initial sync for the entities to synchronize data between both platforms. Many ready-to-use dual-write mappings and integration packages are available and can be enabled via solutions from the Power Platform admin center.

Dual-write is currently mature enough to be used without issues, and Microsoft is investing a lot to make it better. However, there are some considerations before enabling it for an environment. When installed and enabled, it adds new features and limitations to the existing F&O and Dataverse tables and forms, such as new mandatory fields, business rules, and workflow changes. It also introduces data validations from the integrated platform to the existing one; for example, CE users will start seeing F&O validations when they add a new customer. Another thing to mention is the data schema differences between Dataverse and D365 F&O. Dataverse is using “Common Data Model”, which has simple and generic schemas for its master data tables; on the other hand, D365 F&O can have quite complex data structures like trade agreement and pricing modules or directory and party structures for storing contact information and addresses. So it is quite challenging to keep two different data structures in harmony with each other.

Dual-write has a consolidated error logging mechanism, which makes it possible to catch errors on both sides. However, in practice, it is quite difficult to track an error, mostly requiring you to enable debug mode (severe performance impact) and debug on both sides.

More info: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-home-page

Virtual entities

Virtual entities expose the data from D365 F&O entities to Dataverse as virtual links, which allow you to use real-time data from D365 F&O in Power Platform modules, similarly to Dataverse entities. Configuration is automatically done on the Power Platform side when you link it with F&O. Once configured, you can select the entities you want to enable as virtual entities from the list available in Dataverse and use them directly in Power Apps or Power Automate:

Virtual entities work as a link, a placeholder for the actual data sitting on the F&O side. By default, all the CRUD operations on the virtual entities are supported. Any data operation you perform on the virtual entity is directly performed on the F&O data, without duplicating the data in Dataverse. However, creating and updating F&O data directly from virtual entities is not very handy. Validations and lookups on the F&O fields, extended data types, and field lookups are not available in virtual entities. All the complex data types and relations in F&O are presented in the Dataverse virtual entity as flat free-text format. So, data modified in a virtual entity is only validated after it is written to the F&O table. Therefore, virtual entities are more useful for browsing data from D365 F&O in a read-only way, or for visualizations.

Not all field types from the F&O entity are supported by virtual entities, like calculated fields. Also, there are limitations in usage compared to Dataverse native entities, like you cannot join it to another Dataverse entity, and use offline caching.

More info: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/power-platform/virtual-entities-overview

Consuming external web services

In addition to the standard integration features of D365 F&O, there is also a possibility to integrate with external APIs or Azure services using custom X++ code or libraries. I recommend you build a separate .NET library for your external API integrations to avoid hitting some limitations you might experience with F&O CLR-Interop (like async features and collections). In D365 F&O, you can easily add .NET libraries to your VS solution and reference them to your X++ projects in the same solution.

Creating a .NET library inside D365 F&O is tricky and requires good .NET skills and experience. You need to target the same .NET framework as the F&O projects of the time (at the time of writing, .NET Framework 4.7.2). Then, you need to use the newest and most stable .NET HTTP client that is supported by the framework (unfortunately, none of the new .NET Core ones). X++ does not support the async keyword nor the async tasks of .NET, so you need to convert the async call to sync using Task.GetAwaiter().GetResult() method. This can potentially introduce deadlock risks, and in my own experience, it does fall into deadlocks. To remedy it to some point, you need to decorate the async methods in your library with ConfigureAwait(false), and design your module to avoid deadlocks as much as possible.

For these reasons, I do not have a blog post to showcase how it is done, and I recommend that you use this option sparingly and carefully, only for desperate scenarios.

The web service you are trying to access might also be operating in async web service mode. Async web services are special ones that callers do not have to wait until the operation is complete, but respond immediately with a 202 Accepted message and return an inquiry link for polling until a response is available. Afterward, you need to check if the operation is completed by using polling from your caller code.

Once your library is complete and connected to your X++ class, you can use standard X++ calls to retrieve data from the external service, then transfer the data to C# using C# model classes. Model classes of your connected module can be accessed directly from X++ by using the “include” keyword.

Entity store (legacy)

Entity store publishing is deprecated in March 2025 and replaced by the Synapse link feature

Entity store integration pushes normalized D365 F&O data entity data to an Azure SQL database to be used read-only by Microsoft BI tools. Entity store data can be updated manually or using batch jobs. As necessary, there is also an option to develop custom aggregate measures using D365 F&O development tools. As you can guess, this integration is read-only and, in fact, currently only available to MS Power BI. The reason is that, in D365FO production environments, these AXDW databases are not accessible to end users, and you cannot get authorization for any other third-party app if you need to use the same database for your own purposes. BYOD, on the other hand, which we will mention in the next topic, makes this possible by exposing entity store data to a user database instead.

More info: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/analytics/power-bi-integration-entity-store

Bring your own database (BYOD)

Bring your own database publishing is no longer recommended from March 2025 and Synapse link feature is recommended as a replacement

BYOD allows you to export entity data to a user-created SQL Server database instead of the Entity store AXDW, which is currently not allowed to be accessed by end users in production environments. Using BYOD, you can export D365FO data entities to your database manually or with batch update or change tracking options using the standard DMF export projects page. To start using BYOD, you need to configure your SQL Server database in the “Data management” workspace, “Configure Entity export to database” tile:

Then you can use the Publish button to create SQL tables for selected data entities in the target database. After these steps are completed, you can export the data to your SQL database using DMF export jobs and selecting your BYOD SQL Database from the list as a target.

More info: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/analytics/export-entities-to-your-own-database

Export to data lake (legacy)

Export to data lake is deprecated in March 2025 and replaced by the Synapse link feature

Azure data lake publishing provides a more practical, cheaper, and faster storage option for your big analytical and integration databases. It can publish data from entity store, data entities, and standard FO tables to a Data Lake Storage Gen2 storage, in a “near real-time” speed using the new D365 F&O “Data feed service”. Data transfer is using a CSV format, which can be inefficient compared to modern data transfer formats.

Publishing your data into a data lake storage brings in many benefits. It costs much less to store data in a Data Lake compared to a SQL Server data space in Azure. Plus data lake allows you to combine your FO data with data from other applications, and also Dataverse inside the same data lake space, and run consolidated reports with them. Data lake supports the “Common Data Model” folder structure, which can be understood by many cloud applications and services. Usage of Azure data transformation tools like Azure Data Factory is also possible.

D365 F&O has a “Export to Data Lake” form, and you can choose to push the Entity Store to Azure data lake from the Entity Store window:

More info: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/azure-data-lake-overview

Azure Data Factory F&O connector

Microsoft recommends using the Link to Fabric and Fabric Data Factory instead

Azure Data Factory is an integration service in Azure that performs bulk data transformations and integrations using low-code, serverless ETL (extract, transform, load) data pipelines. It extracts data via data connectors, including one for D365 F&O called Dynamics AX connector (yes, the old name). As you can guess, this connector also uses OData under the hood, and the copying is done in bulk via ADF background services. However, the ADF sink option, which chooses the data storage destination, is not available for the Dynamics AX connector.

We also have a D365 F&O connector for the logic apps, which can also do data transforms and integrations, so what is the difference? Compared to logic app-based data transforms, which process records one by one, ADF can perform data transformations much faster in bulk processing using data transform and integration-specific tools. However, operation costs are higher compared to logic app-based integrations.

More info: https://learn.microsoft.com/en-us/azure/data-factory/connector-dynamics-ax?tabs=data-factory

Azure Synapse Link

Azure Synapse Link for Dataverse is the new tool available by Microsoft to export F&O data to low-cost Azure Data Lake Storage Gen2 storage and/or an Azure Synapse Analytics workspace. Linking is done via the Power Platform Synapse link tab, selecting the F&O entities and tables to be linked for export.

The operation of Synapse Link data export is similar to the legacy export to data-lake option, and it covers all the previous benefits of it. Added benefits are that data transfers and storage can now be done in efficient Parquet or Delta formats, there is a continuous replication option, and there is better collaboration with other Microsoft apps in analytical projects inside the Synapse Analytics workspace.

Once you load the F&O data, you can run analytical projects inside Synapse Analytics together with the data extracted from other sources. Results from these projects can then be used, for example, by BI tools like Power BI or integrated into new data sources using pipelines.

Currently, not all F&O tables are available on the Synapse link page, but Microsoft is adding them regularly. If you do not see your own custom tables listed, try to enable the “Row version change tracking” option on your table. Although it transfers data to the data lake side with modern and fast parquet and delta formats.

More info: https://learn.microsoft.com/en-us/power-apps/maker/data-platform/azure-synapse-link-select-fno-data#add-finance-and-operations-tables-in-azure-synapse-link

Link to Microsoft Fabric

preview version

Same as Synapse Link for Dataverse, the new kid on the block, Microsoft Fabric, enhances data analytics, business intelligence, and integration capabilities by linking F&O data. Link to Microsoft Fabric option does not require data to be copied into another data storage as the Synapse analytics option, but creates data source shortcuts and caches the data internally using high-performance and efficient ways when needed. Once your data is linked, Microsoft Fabric features the latest Microsoft technology on data analytics, business intelligence, and data integration.

Linking is at the time of writing done via the same Synapse link tab in Power Platform, but selecting the Microsoft One Lake option. By default, it links all Dataverse tables, including F&O tables linked to Dataverse. Instead of creating extra data lake storage for processing, it uses Dataverse directly if extra storage is needed. You can also connect existing Azure Synapse Links with Microsoft Fabric if you would like to use the new Fabric features, like integrated data pipelines or Power BI DirectLake mode.

Microsoft Fabric charges its costs on a pay-as-you-go, or reservation basis per capacity units, and the lowest cost option is F2. However, the F2 option cannot achieve much, and the recommended ones for a small to medium-scale ERP analytics or integration scenario are F16 or F32, which are considerably more expensive.

At the time of writing, it is still in preview. Please check the Microsoft information link below to get the latest, up-to-date information.

More info: https://learn.microsoft.com/en-us/power-apps/maker/data-platform/azure-synapse-link-view-in-fabric#comparing-link-to-fabric-with-azure-synapse-link-for-dataverse

Finance and operations MCP server

MCP servers stand for standardized plug-ins for AI platforms, which enable AI agents to access data and perform operations on external services. The F&O MCP server allows CoPilot and other MCP-compatible AI agents access to certain F&O business logic as tools. At the time of writing, the number of tools is limited to 13 (listed here), and the tools and their functionality are not extensible. Accessing F&O data directly by using this MCP server is also not possible.

Adding the F&O MCP server to CoPilot is straightforward; just select the “Dynamics 365 ERP MCP” from the list of tools for the agent. Currently, no instructions are available about adding it to other AI platforms.

If you need an F&O MCP server with more tools and possibilities, you either need to wait until this one gets improved or use 3rd third-party F&O MCP server options available on the internet. Another option is to create your own MCP servers using Logic Apps, which I have described in my blog post here.

More info: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/copilot/copilot-mcp