How to Integrate Dynamics 365 Finance & Operations with Dynamics 365 CRM

Many organizations run both Dynamics 365 Finance & Operations (F&O) and Dynamics 365 CRM app — Sales, Customer Service, or Field Service. The two work well side by side, but they don't share data automatically; that connection has to be deliberately built. Microsoft supports several distinct ways to do it, each suited to a different combination of data volume, latency requirement, and technical complexity, and changing your approach later tends to be expensive once gaps in it start showing up in production.

This guide covers each integration option, its prerequisites, how implementation typically flows, how to validate that it's working, and the practices that hold up across all of them — so you can pick the right approach, or the right combination, for your own environment.

Why This Integration Matters

CRM handles the customer side of the business deals, service cases, field visits. F&O handles the operational side invoicing, inventory, pricing, order fulfillment. When they're disconnected, the gaps show up on their own outdated information, duplicate records, manual re-entry, and teams working from different versions of the truth.

Connect the two properly and most of that friction just goes away. Everyone works from the same information instead of their own version of it.

Prerequisites

A few things need to be in place before evaluating which approach fits, regardless of which one — or combination — you land on:

• An F&O environment linked to a Power Platform environment, on the same Microsoft Entra tenant — every native pattern here (Dual Write, Virtual Tables, Business Events, Data Events) depends on that link existing first.
• System administrator (or equivalent) access in both F&O and the Power Platform admin center, since enabling integration features and installing solutions require elevated permissions on both sides.
• A sandbox (non-production) environment to configure and test in first. Several of these features, including the initial Power Platform link and Dual Write's initial sync, aren't easily reversible once enabled.
• For the custom-development routes — Custom APIs, Logic Apps, Service Bus — an Azure subscription and a development/testing environment in addition to the above.

Each approach also has its own specific setup requirements beyond this baseline, covered in its section below.

1. Dual Write — Real-Time, Two-Way Sync

Dual Write keeps data synchronized between F&O and Dataverse-based apps like Sales, Customer Service, and Field Service. Update a record in F&O and the change reflects in CRM almost immediately; update it in CRM and it writes back to F&O just as fast. Microsoft ships preconfigured mappings for the obvious things — customers, vendors, products, sales orders — and you extend or build custom ones for anything specific to your business, usually with minimal coding.

A few things worth knowing:

• It's a strict one-to-one connection — one F&O environment linked to one Dataverse environment, not several.
• Data syncs in a defined order rather than all at once, which is what keeps related records from landing out of sequence with each other.
• The two systems don't share number sequences, so if a table can be edited from both sides, you'll want to think through how record numbering is handled before you go live.
• It does work offline, through the Dynamics 365 and Field Service mobile apps — changes made without a connection are held locally and sync once the device is back online.

Prerequisites: you'll need a Power Platform environment linked to your F&O environment on the same Microsoft Entra tenant, the right application users and security permissions set up on both sides, Dual Write and its relevant solution packages installed, and enough Power Platform database storage to support it.

Best for: situations where sales, service, finance, and operations all genuinely need to see the same customer, product, or order record almost instantly — not eventually.

2. Virtual Tables — Live Data Without Duplication

Virtual Tables let CRM access F&O data directly, without storing or copying it into Dataverse. Rather than syncing, CRM pulls the information straight from F&O the moment a user opens or interacts with a record — so a sales rep sees a customer's actual current credit limit, not a nightly-refreshed copy of it. Virtual Tables support genuine create, update, and delete operations too, depending on configuration; any change made through CRM applies directly to the F&O record and follows the same business rules and validation F&O normally enforces.

Worth flagging:

• Speed depends entirely on how fast F&O responds to that call, since nothing is cached anywhere — there's no local copy to fall back on.
• There's no offline mode. If the connection drops, the data simply isn't reachable, because it was never stored anywhere else to begin with.
• A handful of Dataverse-native features — field-level security, record ownership — just don't apply here, since the record technically doesn't live in Dataverse at all.

Prerequisites: Power Platform integration needs to be turned on for the F&O environment, the Finance & Operations Virtual Entity solution has to be installed in Dataverse, and it's a one-to-one relationship — one Dataverse environment, one F&O environment, same Microsoft Entra tenant.

Best for: letting someone view or occasionally edit live F&O data from inside CRM, when what you actually need is a window into the data — not a permanent, synced copy of it.

3. Power Automate — Low-Code Automation

Power Automate is the low-code option: build a flow that follows a simple rule — when this happens, do that. Mark an Opportunity Won in Sales, and a flow can automatically create the customer and sales order in F&O, no one touching a keyboard in between.

One thing to check upfront: for real-time triggers from F&O, Power Automate relies on Business Events, and the specific event you need has to actually exist and be activated. If it doesn't, you fall back to a scheduled flow that checks for changes at set intervals, which introduces some lag.

When the trigger situation works out, Power Automate is quick to implement, easy to maintain, and gives detailed run history for troubleshooting — a strong fit for approvals, notifications, and small-to-medium integrations. High-volume transactions or complex data transformations are better handled by Business Events, Logic Apps, or custom middleware.

Prerequisites: a Power Automate license that supports the required connectors (typically premium for the Finance & Operations connector), a configured F&O connection, the right security roles, and — for real-time scenarios — an active Business Event in F&O. Without one, you're building a scheduled flow instead.

Best for: quick approval workflows, notifications, and small-to-medium automations that don't justify a development project.

4. Business Events and Data Events — Event-Driven Updates

F&O provides two related but distinct event mechanisms. Business Events fire when an actual business process completes — an invoice posts, a purchase order gets approved, a workflow finishes — and are meant to notify external systems that something meaningful happened. Data Events fire on a plain create, update, or delete of any OData-enabled entity, with no business-process context — just “this record changed.”

The distinction that decides which to use: a Business Event answers “has this process finished?” (e.g., CRM needs to know an invoice posted); a Data Event answers “did this record change?” (e.g., CRM needs to know a customer record was updated).

Both route through Azure Service Bus or Azure Event Grid to Power Automate, Logic Apps, or a custom application, letting the receiving system process the event asynchronously — useful for shipment or delivery confirmations, order status updates, and monitoring changes to customer, vendor, or product records.

One thing to plan for:

• Events don't always show up in the order they fired, and occasionally the same one arrives twice — so build your consumer to handle both rather than assuming clean, sequential delivery.
• That loose coupling is actually the point: F&O doesn't need to know or care who's listening, which is what makes the pattern scale well.

Prerequisites: Power Platform integration needs to be enabled in F&O (required specifically for Data Events), you'll need an Azure Service Bus namespace or Event Grid topic to receive things, the relevant events have to be activated in the F&O Business Event Catalog, and your receiving system needs to be built to cope with duplicate or out-of-order messages.

Best for: real-time notifications and status updates — anywhere CRM needs to react to something happening in F&O without the two systems being tightly wired together.

5. Custom APIs (OData) — Full Control Integration

Sometimes the standard options don't fully fit, and that's what this route is for. Every F&O data entity marked “Is Public” is automatically exposed as an OData endpoint — standard REST, with GET to query, POST to create, PATCH to update, DELETE to remove, authenticated through Microsoft Entra OAuth2. That covers straightforward CRUD against existing entities like customers, orders, or products.

For anything OData can't do — running real business logic, posting a transaction, checking live on-hand inventory — F&O supports custom services: a developer writes the logic in X++, and it's automatically exposed as a callable SOAP/REST endpoint once deployed. Both are synchronous, and both are throttled by F&O under heavy volume, so anything high-throughput needs retry and backoff logic built in from the start.

On the Dataverse side, the equivalent is the Dataverse Web API. A typical custom integration is middleware that calls both APIs and handles whatever field mapping, transformation, or conditional logic connects them — useful for complex business rules, multi-system orchestration, or connecting a system outside the Dynamics ecosystem entirely.

Prerequisites: Microsoft Entra app registrations with the required API permissions on both F&O and Dataverse, separate development and testing environments, monitoring and error-handling built into the middleware itself, and a realistic plan for ongoing maintenance — this is the one option here without Microsoft-managed upkeep.

Best for: scenarios that Dual Write, Virtual Tables, Business Events, or Power Automate genuinely can't cover — complex transformations, multi-system orchestration, or non-Dynamics connectivity.

6. Azure Logic Apps — Enterprise Orchestration

Logic Apps is enterprise-grade middleware: a visual designer, prebuilt connectors for CRM, F&O, SAP, Salesforce, and databases, with monitoring, retries, and error handling built in from the start. It earns its place once the integration isn't really “CRM to F&O” but “CRM, F&O, and two or three other systems,” and you want one place to see and manage that whole chain instead of a tangle of point-to-point connections.

Prerequisites: you'll need an Azure subscription, the right connectors set up with credentials for each system you're connecting, and some way to actually monitor it — Azure Monitor or similar — since Logic Apps runs outside the Power Platform's own monitoring tools and won't show up there.

Best for: when you're connecting more than just CRM and F&O — SAP, Salesforce, a few other systems — and want one place to see the whole chain instead of a pile of separate connections to keep track of.

7. Azure Service Bus — Reliable Async Messaging

Service Bus takes CRM and F&O out of direct conversation entirely. Instead of one system calling the other, messages land in a queue or topic and get picked up independently by whatever's processing them — an Azure Function, a Logic App, a custom app — with retry and dead-lettering built in for anything that fails along the way. That's exactly the setup you want for genuinely high-volume scenarios where reliability matters more than speed, and where a spike on one side shouldn't be able to take the other one down with it.

Prerequisites: you'll need an Azure Service Bus namespace with queues or topics set up, something to actually publish and process the messages — an Azure Function, a Logic App, or a custom application — and Azure AD authentication configured on both ends.

Best for: high-volume integrations where the two systems need to stay loosely coupled, and where one side going down briefly shouldn't take the other one with it.

8. Batch Data Integration (DMF) — Scheduled Bulk Sync

Batch integrations use F&O's Data Management Framework (DMF) to move data on a schedule rather than in real time — recurring jobs, data packages, or file-based transfers instead of instant, record-by-record sync. It's a common fit for large volumes of data where immediate updates genuinely aren't the requirement: customer records, products, inventory data, or sales transactions exported from F&O and picked up by CRM or another system on a set schedule.

A couple of practical notes:

• It can move data as files, through OData, via BYOD (Bring Your Own Database), or through custom integration endpoints — whichever fits how the receiving system wants to consume it.
• Once you're dealing with genuinely large datasets, this is usually simpler to run and maintain than trying to force a real-time integration to handle the same volume.
• Data will always lag by however long the schedule runs on — hourly, nightly, whatever fits — so it's a poor fit if the business actually needs up-to-the-minute numbers.

Prerequisites: you'll need a defined DMF data project or recurring schedule, staging entities or tables set up for whatever's being moved, the right security roles for import and export, and a target system on the other end ready to pick up the batch on the same cadence.

Best for: large data volumes — master data sync, reporting feeds, historical loads — where near real-time updates just aren't the actual requirement.

Choosing Your Approach

The table below maps common scenarios to the approach most likely to fit, along with the trade-offs that drive the decision.

Common Points of Confusion

Dual Write vs. Virtual Tables — both connect F&O data to Dataverse, but Dual Write duplicates the data and keeps both copies in sync, while Virtual Tables never duplicate anything; they open a live window into F&O. The deciding question: does this data need to physically live inside Dataverse (Dual Write), or is a live, on-demand view enough (Virtual Tables)?

Business Events vs. Data Events — “I need to know when this business process finishes” is a Business Event. “I need to know when this record changed” is a Data Event. Using a Data Event to capture a multi-step business process misses context the payload was never designed to carry.

Power Automate vs. Logic Apps — Power Automate is built for business users and departmental automation; Logic Apps is built for IT-owned, enterprise-scale orchestration with tighter DevOps and monitoring needs. A flow that started in Power Automate often gets rebuilt in Logic Apps once it becomes business critical.

Real-time vs. Batch — before reaching for any real-time pattern, ask whether the business actually needs instant updates. If a scheduled sync genuinely covers the need, Batch Integration (DMF) is far simpler to set up and maintain than any of the real-time options.

Most real implementations end up combining two or three patterns rather than picking one — Dual Write for the core customer and product sync, Business Events or Data Events for status updates, and Virtual Tables for the occasional live lookup that doesn't justify a full sync pipeline.

Read moreCase study: Keeping Dynamics 365 CRM and Finance & Operations in Sync

Best Practices

No matter which approaches you choose, these practices help ensure a reliable, maintainable integration:

• Define a system of record. Decide whether CRM or F&O owns each shared piece of data to avoid conflicts and duplicate updates.
• Choose the right tool for the requirement. Not every scenario needs Dual Write — Virtual Tables, Business Events, or Power Automate are often simpler and easier to maintain.
• Favor asynchronous integrations where possible. Event-driven and message-based patterns are generally more scalable and resilient than direct system-to-system calls.
• Plan for failure. Build in retries, error handling, monitoring, and alerts so issues get caught and resolved quickly.
• Secure integrations properly. Use Microsoft Entra authentication, least-privilege access, and review permissions regularly.
• Test thoroughly before production. Validate data mapping, business processes, and error scenarios in sandbox first.
• Document ownership. Make it clear who's responsible for maintaining each flow, mapping, API, or Logic App once it's live.

Conclusion

None of these approaches is “the best” — they solve different problems, and the expensive mistake isn't choosing one option over another, it's choosing based on what's fastest to build today instead of what your actual data volume and latency needs require, then re-architecting the whole thing once the gaps show up in production.

Mapping your entities against the prerequisites, implementation steps, and validation approach for each pattern before you build anything is what turns this from a guess into a decision — whether that ends up being a single approach or a combination working together.

If you'd like a second opinion on which pattern fits your environment, our Dynamics 365 integration services team can help you map it out before you build.

Written by

Kishan Suthar

Technical Consultant

Kishan is a skilled Technical Consultant at Dynamic Day Technologies, specializing in MS Dynamics. With extensive expertise in streamlining business processes and providing tailored Microsoft solutions, Kishan is committed to helping organizations optimize their operations through innovative and effective ERP systems.

More from Kishan →