How to integrate with Dynamics 365 Finance and Operations Part -4

11) Data Events

Data events in Dynamics 365 F&O function similarly to business events, as they are triggered by CRUD (Create, Read, Update, Delete) operations performed on data entities. These events can be activated and managed directly from the Business Event Catalog form.

However, unlike traditional business events, data events are tightly integrated with the Power Platform. This means that Power Platform linking must be enabled in your environment to use them. Once configured, triggered data events can be published to defined endpoints in the Business Event Catalog or consumed directly through Power Automate triggers for the associated virtual entity.

⚠️ Note: Dynamics 365 F&O imposes limits on the number of data events that can be triggered per hour. Because of this throttling, data events are not ideal for high-volume entities (such as products) that undergo frequent bulk updates.

✅ Advantages

• Provides real-time updates for CRUD operations on activated data entities.

• Enables seamless integration with Power Automate and other Power Platform services.

❌ Disadvantages

• Requires an active Power Platform link between F&O and Power Platform.

• Event limits and throttling may impact performance in high-transaction scenarios.

🔍 Learn more:
Read the official documentation — Data events overview | Microsoft Learn

12) Virtual entities

Virtual entities enable real-time integration between Dynamics 365 Finance & Operations (F&O) and the Power Platform by exposing F&O data directly in Dataverse. These virtual links allow Power Apps, Power Automate, and other Power Platform components to access and interact with F&O data as if it were stored natively in Dataverse.

When you link your F&O environment with the Power Platform, the configuration for virtual entities is handled automatically. After setup, you can simply select the entities you want to enable as virtual entities in Dataverse and start using them instantly in your low-code solutions.

 

⚙️ How Virtual Entities Work

Virtual entities act as a real-time bridge — a placeholder that connects Dataverse to the actual data stored in F&O. All CRUD operations (Create, Read, Update, Delete) are supported, and any change made in Dataverse is executed directly on the F&O data, without duplication.

However, creating or updating F&O data via virtual entities can be challenging. That’s because validations, lookups, and extended data types from F&O aren’t fully replicated in Dataverse. Complex relationships and data types appear as simplified flat text fields, meaning data is validated only after it’s written back to F&O.

As a result, virtual entities are best suited for read-only scenarios, data exploration, and visualizations, rather than heavy data manipulation.

⚠️ Limitations

Not all F&O entity field types are supported — for example, calculated fields aren’t available. In addition, virtual entities have limitations compared to native Dataverse entities:

• You can’t join them with other Dataverse entities.

• Offline caching isn’t supported.

✅ Advantages

• Real-time access to Dynamics 365 F&O data in the Power Platform.

• Free Microsoft-provided integration tool.

• Supports CRUD operations directly on F&O data.

❌ Disadvantages

• Not ideal for direct data updates in F&O.

• Complex data types and relationships are simplified in Dataverse.

• Calculated fields aren’t supported.

• Lacks some Dataverse native entity features.

🔍 Learn more:
Virtual entities overview — Microsoft Learn

13)Azure Data Factory Connector for Dynamics 365 Finance & Operations

Starting in 2025, Microsoft recommends using the Link to Fabric and Fabric Data Factory instead of the traditional Azure Data Factory (ADF) connector for Finance & Operations.

Azure Data Factory is a powerful, cloud-based integration service in Azure that allows you to perform bulk data transformations and integrations using low-code, serverless ETL (Extract, Transform, Load) pipelines. It can connect to multiple data sources through native connectors — including one for Dynamics 365 F&O, still called the Dynamics AX connector (a legacy name).

Under the hood, this connector uses OData for data extraction, and the copying happens in bulk via ADF background services. However, it’s important to note that the sink option — which defines the target storage for your data — is not supported for the Dynamics AX connector, making this a one-way integration from F&O outward.

ADF vs Logic Apps

Dynamics 365 F&O also provides a Logic Apps connector that can handle data integration and transformation tasks.

So, what’s the difference?

• Logic Apps process data record by record, offering fine control for smaller transactions.

• Azure Data Factory, on the other hand, is optimized for high-volume, bulk data transformations, making it more efficient for large-scale ETL operations.

However, ADF’s performance advantage comes with higher operational costs compared to Logic App–based integrations.

✅ Advantages

• ⚡ High-performance bulk data transformations

• 🧩 Serverless, low-code pipeline design

• 🔗 Native data ingestion from Dynamics 365 F&O

• 🔄 Ability to use a wide range of out-of-the-box data connectors and processing tools

❌ Disadvantages

• 💰 Higher operation costs compared to Logic Apps

• 🐢 Uses OData, which can be slower for large datasets

• 🚫 Sink option unavailable for F&O — supports one-way data integration only

🔍 Learn more:
Azure Data Factory Dynamics AX connector — Microsoft Learn

🔍 Stay tuned for more D365FO technical posts

📌 Bookmark: https://d365fohunt.blogspot.com

How to integrate with Dynamics 365 Finance and Operations Part -3

7) Bring Your Own Database (BYOD) 

As of March 2025, Microsoft has deprecated the Bring Your Own Database (BYOD) publishing approach. The recommended replacement is Synapse Link for Dynamics 365 F&O, which provides a more modern, scalable, and real-time data integration experience.

Let's you export D365 FO data to your own Azure SQL database.

BYOD allows you to export entity data to a user-created SQL Server database instead of the Entity store AXDW, which is currently not accessible 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.

✅ Key Features of BYOD:

1. Custom Reporting:

   • Use tools like Power BI, SSRS, Excel, or third-party apps to run reports directly on exported data.

2. Azure SQL Support:

   • Exported data lands in a customer-provisioned Azure SQL Database, enabling flexible access.

3. Data Entities:

   • Uses data entities to define the structure and scope of the data being exported.

4. Incremental Push:

   • Supports full or incremental data push, minimising data transfer and improving performance.

5. Scheduled or Manual Exports:

   • Data exports can be triggered manually or on a schedule using batch jobs.

🛠️ How to Configure BYOD:

1. Provision Azure SQL Database

   • Create a SQL Database in Azure (with appropriate firewall and access configurations).

2. Register Database in D365FO

   • Go to Data Management > Bring your own database.

   • Register and validate your Azure SQL connection.

3. Publish Data Entities

   • Choose the data entities you wish to export and publish them to the registered BYOD.

4. Export Projects

   • Create and configure data export projects to schedule exports to BYOD.

🔐 Security and Access:

• Use read-only access to the BYOD database for reporting purposes.

• Be cautious with sensitive or PII data—ensure your access model complies with your organisation's security policies.

⚠️ Limitations and Considerations:

• No automatic schema updates: If you update a data entity in D365FO, you must republish it to BYOD.

• BYOD is read-only; no reverse synchronisation to D365FO.

• Does not support all entities (especially non-persisted or virtual entities).

• Consider Export to Data Lake a modern alternative for large datasets or near-real-time scenarios.

• Use case: Full control over data for downstream apps or reporting.

• Setup: Define entities to export via the data management framework.

✅ Ideal for complex BI environments or legacy system syncs.

 🔍 Learn more:

Bring your own database (BYOD) overview | Microsoft Learn

8) Azure Data Lake/Export to Data Lake (legacy)

Starting March 2025, Microsoft is deprecating the Export to Data Lake feature. The new and recommended solution is Synapse Link for Dynamics 365 F&O, offering a more efficient and real-time data integration experience.

With the Export to Data Lake feature, D365 FO continuously exports data entities to Azure Data Lake Gen2.

A feature still in public preview, Azure data lake publishing provides a more practical, cheaper and faster storage option for your big analytical and integration databases, which you used to access using Entity store or BYOD options before. 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 D365FO “Data feed service”. This new data feed service works faster and saves you the hassle of maintaining DMF export jobs and batches.

Publishing your data into a data lake storage brings 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 CDS inside the same data lake space and run consolidated reports with them. Data lake supports Common Data Model folder structure, which can be understood by many Cloud applications and services, and it is also possible to move the data from and to CDS using CDS Data lake integrations. Usage of Azure data transformation tools like Azure Data Factory is also possible.

All in all, it brings you a couple of steps closer to Azure cloud integration and provides you with the future-proof “near-real-time” data synchronisation.

At the time of writing, Azure data lake options are still in public preview and need to be enabled from the D365FO “Feature management” window first. Then you will be able to choose tables to be published to the data lake from the “Export to Data Lake” form and push the Entity Store to the Azure data lake from the Entity Store window:

✅ Advantages of Azure Data Lake with D365FO

Advantage	Description
Near Real-Time Data Export	Automatically syncs entity data to Data Lake with minimal delay—ideal for up-to-date reporting.
No Need to Republish Entities	Unlike BYOD, you don’t need to republish when the data model changes—auto-handled by the platform.
Scalable Storage	Can handle petabytes of data efficiently; no size restrictions.
Open Data Format	Stores data in open formats (CSV/Parquet), which are supported by most analytics tools.
Advanced Analytics Ready	Easily connects with tools like Power BI, Azure Synapse, Databricks, and Azure ML.
Better Performance	Offloads heavy reporting from the D365FO database, improving overall performance.
Secure & Compliant	Uses Azure security, RBAC, and encryption; suitable for enterprise-grade deployments.

❌ Disadvantages of Azure Data Lake with D365FO

Disadvantage	Description
Read-Only Data	You cannot write back to D365FO—one-way export only.
Initial Setup Complexity	Requires coordination between the D365FO team and the Azure team (security, firewall, permissions).
Azure Knowledge Required	You need a basic understanding of Azure Storage, IAM, Synapse, etc., for effective usage.
No Ad-Hoc SQL Queries	Unlike BYOD (Azure SQL DB), you can’t directly query using SSMS or ad-hoc SQL.
First-Time Sync Delay	Initial sync of large volumes can take time, especially in Production environments.
Custom Entity Support Limited (Initially)	Only selected entities are available out-of-the-box; custom entities require extra setup or a workaround.

• Use case: Big data analytics, integration with Synapse or custom data lakes.

• Architecture: Fully managed and scalable.

✅ Best for enterprise-scale analytics and centralised data platforms.

🔍 Learn more:

Check out Microsoft’s official documentation for details on the Export to Data Lake feature —
Export to Data Lake overview — Microsoft Learn

9) Dual Write

A near-real-time bi-directional sync between D365 FO and Dataverse (Power Platform).

Dual-write is a real-time, bi-directional integration between Dynamics 365 Finance and Operations (D365FO) and Dataverse (Power Platform + CE apps like Sales, Customer Service, etc.).

It provides seamless data synchronisation so that records created or updated in one app (e.g., FO) automatically reflect in the other (e.g., CE), and vice versa, without the need for custom integrations or data sync jobs.

🧩 Key Concepts

Feature	Description
Entity Mapping	Maps D365FO tables (data entities) with Dataverse tables (entities).
Real-time Sync	Updates flow instantly between systems.
Out-of-the-box Templates	Microsoft provides prebuilt mappings for common entities (Customer, Vendor, Product, etc.).
Custom Entity Support	You can define custom mappings for custom tables/entities.
Power Platform Integration	Enables usage of Power Apps, Power Automate, AI Builder with FO data.

✅ Advantages of Dual-write

Advantage	Description
Real-time Data Flow	Any change in D365FO or Dataverse reflects instantly in the other system.
No Need for Manual Integration	Eliminates need for custom middleware or ETL tools between CE and FO.
Unified User Experience	Sales, Finance, and Operations users work with one version of truth.
Tight Integration with Power Platform	Use FO data in Power Apps, Power Automate, AI Builder, etc.
Prebuilt Templates	Microsoft provides more than 30 ready-to-use mappings to speed up setup.
Custom Mappings	Supports extensibility for ISVs and partners.
Error Handling UI	Errors are logged with detailed traceability in the UI with retries and fixes.

❌ Disadvantages of Dual-write

Disadvantage	Description
Initial Setup is Complex	Requires careful setup and validation, especially in large or customised implementations.
Performance Overhead	Real-time sync can cause latency or impact performance if not managed properly.
Customization Conflicts	Customisations in FO or CE can break mappings or cause sync issues.
Tightly Coupled Systems	High dependency between FO and Dataverse can become a risk during updates or outages.
Monitoring and Maintenance	Requires regular monitoring, handling sync failures, and managing error logs.
Limited Offline Capability	Dual-write only works when both systems are online and reachable.

🏗️ Typical Use Cases

• Sales to Cash Integration
  Customer data entered in Dynamics 365 Sales (CE) syncs with D365FO for invoicing and fulfilment.

• Product Sync
  Products created in FO are synced to CE so sales reps can quote and sell accurately.

• Vendor Management
  Vendors created in CE (via Power Apps) get synced to FO for procurement processes.

• Use case: Sync customers, orders, vendors, etc., with Power Apps or D365 CE.

• Setup: Prebuilt mappings and extensible framework.

✅ Great for connected apps, low-code solutions, and seamless FO + CE experiences.

🔍 Learn more:
Dual-write overview | Microsoft Learn

10) Consuming External Web Services (from X++)

D365 FO can consume external API's directly via X++.

🔍 Overview

D365FO supports integration with external systems via HTTP-based web services (REST/SOAP). As a technical consultant, you often need to call third-party APIs for real-time data exchange like:

• Fetching exchange rates

• Sending invoice data to an external system

• Validating GST/TIN

• Sending SMS or email notifications

This article explains how to consume external REST/SOAP web services from X++ using System.Net.HttpWebRequest, System.Net.HttpClient, or a custom .NET class wrapper in D365FO.

🔐 Security Considerations

• D365FO runs in sandboxed environments, so HTTP calls are allowed only from batch or async operations.

• Use Azure Key Vault to store API keys or secrets securely.

• Use Sys.Net.HttpClient only in trusted and controlled scenarios.

• Avoid direct synchronous API calls in forms or synchronous processes.

🛠️ Common Use Cases

Use Case	API Type	Call Type
Get weather data	REST	GET
Validate GSTIN/PAN	REST	POST
Send SMS via Twilio	REST	POST
Fetch stock prices	REST	GET
Submit Invoice to Tax Portal	SOAP	POST

🚧 Best Practices

• Use Batch Jobs or SysOperation Framework for calling external APIs.

• Log responses for traceability in a custom log table.

• Implement retry logic for transient failures.

• Use Sys.Net.HttpClientFactory if you're managing many connections.

📝 Summary

Feature	REST (HttpClient)	SOAP (Service Ref)	.NET DLL
Ease of Use	✅ Easy	⚠️ Moderate	✅ Flexible
Real-time	✅ Yes	✅ Yes	✅ Yes
Reuse Logic	⚠️ Low	⚠️ Medium	✅ High
OAuth/JWT Support	✅ Yes (custom headers)	❌ Manual	✅ Excellent

• Class used: System.Net.HttpClient, CLRObject, etc.

• Use case: Call a shipping API to get tracking info, or sync the external catalogue.

✅ Enables integration with external REST/SOAP services from within D365 FO.

✅ Final Thoughts

D365 FO offers integration options for every need — real-time APIs, bulk syncs, event-driven messaging, and analytics.

🔍 Stay tuned for more D365FO technical posts

📌 Bookmark: https://d365fohunt.blogspot.com