Most conversations about Dynamics 365 integration patterns start by naming a tool. Dual-write, or a Logic App, or a nightly export. The tool gets chosen early because someone on the team has used it, and everything afterwards is an argument about how to make that choice work.
There is a question that comes before the tool, and answering it removes about half the options immediately: does the data need to be copied into Dataverse at all?
That is not a semantic distinction. Copying data creates a second copy that has to be kept correct, and every mechanism for keeping it correct has a failure mode, an error queue and an operating cost. Not copying it has one failure mode, which is that the source is unavailable. Teams reach for replication by default and pay for it for years.
The three inbound families
Microsoft groups the ways data gets into Dataverse into three, and the grouping is more useful than the individual product names because it maps to three different levels of commitment.
Dataverse APIs. The Organization service defines every platform operation as a message and is reached through the .NET SDK. The Web API exposes the same operations over HTTP, using OData to define functions and actions. This is the maximum-control option and the maximum-maintenance one.
Dataverse connectors. Power Automate and Logic Apps, moving data in through prebuilt connectors with little or no custom code. The distinction between the two is worth getting right because it is not a capability distinction. Power Automate is for orchestrating events and comes included in many Power Platform and Dynamics 365 offerings, so it is often already paid for. Logic Apps is an Azure resource, suited to professional development, and gives greater control and flexibility. The choice is usually about who will own the thing in two years, not about what it can do.
UI integration. Virtual tables and custom controls, which surface external data inside Dynamics 365 without importing it. Dataverse ships virtual connector providers for common sources including SQL Server, SharePoint, Fabric and OData.
That third family is the one that answers the copy-or-connect question, and it is consistently the least considered.
Virtual tables are the option you should rule out first
Not because they are best. Because ruling them out is fast, and if you cannot rule them out you have saved yourself a replication pipeline.
A virtual table represents external data as a Dataverse table. Solutions, apps and flows treat it like any other table, and there is no replication. The data is read on demand from wherever it lives.
The reasons to reject virtual tables are real and they are usually one of these: you need the data offline, you need it in a rollup or a workflow that cannot tolerate source latency, the source cannot take the query load, or you need history the source does not keep. Each of those is a legitimate answer and each takes about a minute to establish.
What we see instead is that virtual tables rarely enter the conversation at all, because they feel like a workaround while dual-write feels like the supported path. That instinct is backwards, and the next section is why.
Dual-write is a schema decision
Dual-write does what it says. It provides tightly coupled, bidirectional, near-real-time integration between finance and operations apps and Dataverse. A change on either side writes to the other. It ships with play, pause and catchup modes, initial data synchronisation, combined activity and error logging, configurable alerts and thresholds, and a filtering and transformation interface. As integration infrastructure it is genuinely strong.
Here is the part that belongs in a design review and rarely gets there. Dual-write consists of two marketplace solutions that you install into Dataverse, and those solutions expand the table schema, plugins and workflows so they can scale to ERP size. Installing it changes your Dataverse data model:
| What dual-write adds to Dataverse | Consequence |
| Company and party concepts | Apps built on Dataverse now sit inside an ERP-shaped organisational model |
| Activities and notes unified and expanded | They support both users of the system and customers of it, which changes an existing entity many solutions already depend on |
| Date effectivity | Tables can carry past, present and future data on the same row set |
| Currency decimal extension to 10 places | Opt-in. Existing rows are autotranslated at the metadata layer, and currency values move from money data to decimal data |
| Product unit conversions | Applied across products, quotes, orders and invoices |
Microsoft’s own framing is that if you understand this plan, you can avoid some design and development rework in the future. That is a carefully worded sentence. Read plainly, it says: this is not a connector you switch on beside your existing model, it is a modification of the model, and solutions you have already built need to be assessed against it.
None of that is an argument against dual-write. It is an argument for treating the decision as an architecture decision with a schema impact assessment attached, rather than as a configuration task on an integration workstream. The currency change alone, moving values from money to decimal at the metadata layer, is the kind of thing that should be signed off by someone who understands what reads those fields today.
Outbound is a different decision entirely
Getting data out of Dataverse has its own set, and they separate cleanly by latency and by who bears the load.
- Plugins run in the platform and can call external services directly or post runtime context to Azure Service Bus or Event Hubs. Posting to a broker rather than calling a service is almost always the better shape, for reasons the command or event distinction covers in detail.
- Webhooks are a lightweight HTTP pattern for real-time, event-driven integration. They suit low-latency requirements where the external system can handle a high volume of messages. That qualifier is the whole risk. A webhook makes your receiver’s throughput a hard dependency of your Dataverse write path.
- Business events give asynchronous integration without polling and without custom logic to detect change.
- Azure Synapse Link for Dataverse continuously exports to Synapse Analytics and Data Lake Storage, which is the right answer for analytics, business intelligence and machine learning, and the wrong answer for anything a user is waiting on.
- Change tracking supports delta updates for scheduled work.
The reason to list them this way is that the first question is not which one, it is whether anyone is waiting. If a person or a process is blocked until the data arrives, you are in the top two. If the destination is a report, you are in Synapse Link and you should stop designing an event pipeline.
Our position: the coupled option should be the last one you reach for
We think the sequence should run outwards from least commitment to most: can we not copy it, can we copy it on a schedule, can we copy it on an event, do we genuinely need bidirectional near-real-time coupling.
Almost nobody runs it in that order. The order we see is that dual-write is evaluated first because it is the named, supported, Microsoft-built option, and everything else is treated as a fallback for when dual-write does not fit. The consequence is estates carrying a tightly coupled bidirectional synchronisation to serve a requirement that a nightly export would have met, and carrying the schema changes and the error queue that come with it.
The test we apply is a question about direction, and it is worth asking in exactly these words: does data genuinely need to move both ways within seconds, or is the other direction theoretical? If it is theoretical, you have a one-way requirement wearing a bidirectional label, and it should not cost you a schema change to satisfy it.
The integration that never wrote back
A Dynamics 365 Finance and Operations client had dual-write running to a partner order portal. Full bidirectional, catchup mode enabled, the lot. Reviewing it eighteen months in, the write-back direction had never fired once in production.
The portal only ever needed to read order status. Nobody on that side had a workflow that wrote anything back, and nobody ever had. It was built bidirectional because that is the connector default, not because anyone had asked whether the requirement was bidirectional.
Removing the write-back half took an afternoon, and it cleared a chunk of an error queue nobody had been triaging.
That last detail is the part worth carrying. The cost of an unnecessary bidirectional integration is not only the schema change. It is a stream of failures in a direction nobody is watching, which means nobody triages them, which means the queue is useless as a signal by the time something in the direction you do care about breaks.
We do not have a formal count of how often this happens and we are not going to invent one. What we will say plainly is that more of the integrations we review as bidirectional turn out to be one-way in practice than the reverse. Somebody built for symmetry a requirement nobody had asked for.
The fifth factor
Microsoft names four factors for choosing between all of these: the complexity of the integration, the volume of data, the need for real-time processing, and the existing infrastructure.
To those we add a fifth, which is who operates this at 2am, eighteen months from now. That question changes the Power Automate against Logic Apps answer more often than any technical criterion does. A team that owns nothing else in Azure should not inherit a Logic App because it is the more capable product. They will not touch it again after go-live, and it will fail quietly. The same question decides whether a workload should run on Container Apps or AKS.
Where this connects
Two adjacent decisions, both of which sit underneath the pattern choice.
The synchronisation question, meaning how often and in which direction data moves and who is the record keeper, is a layer below the tool. Why real time is usually the wrong answer in ERP integration covers that layer and applies directly here.
And once you have decided to move messages, the transport choice has its own logic. Whether you are sending a command or announcing an event determines which Azure service is correct, and getting it wrong is the most common integration error we review.
Broader platform work sits under data integration.
Where to start
Take your integration list and mark each line with one word: copy, or connect.
For everything marked connect, check whether a virtual table serves it. For everything marked copy, ask whether the copy needs to go both ways, and be strict about the answer. Bidirectional is a claim that has to be earned by a real business process, not by a preference for keeping things in sync.
Then, before dual-write is approved anywhere, get the schema changes on a page and in front of whoever owns the existing Dataverse solutions. Company, party, activities, date effectivity, currency precision. Half an hour of review now is cheaper than a rework cycle later, and Microsoft says as much in its own documentation.
Veratas designs and builds Dynamics 365 and Dataverse integrations, including the architecture work that decides which pattern you should be using.
If you have an integration that is bidirectional because nobody questioned it, talk to our team. Simplifying one is usually cheaper than maintaining it.
Frequently asked questions
What are the main Dynamics 365 integration patterns for Dataverse? Inbound, Microsoft groups them as Dataverse APIs (the Organization service through the .NET SDK, and the Web API over HTTP with OData), Dataverse connectors (Power Automate and Logic Apps), and UI integration (virtual tables and custom controls). Outbound, the set is plugins, webhooks, business events, Azure Synapse Link for Dataverse, and change tracking for delta updates.
When should I use virtual tables instead of copying data? Whenever the data can be read on demand and does not need to be available offline, used in rollups that cannot tolerate source latency, or retained beyond what the source keeps. Virtual tables represent external data as Dataverse tables with no replication, so there is no pipeline to operate and no second copy to reconcile.
Does installing dual-write change my Dataverse environment? Yes, and this is the point most often missed. Dual-write installs two marketplace solutions that expand the Dataverse table schema, plugins and workflows to ERP scale. It introduces company and party concepts, unifies and expands activities and notes, adds date effectivity, offers an opt-in currency extension to 10 decimal places that converts money data to decimal at the metadata layer, and adds product unit conversions.
What is the difference between Power Automate and Logic Apps for Dataverse integration? Capability overlaps heavily. Power Automate is aimed at orchestrating events and is included in many Power Platform and Dynamics 365 offerings. Logic Apps is deployed as an Azure resource, is better suited to professional development, and gives greater control and flexibility. In practice the deciding factor is who will own and operate the integration long term.
Which outbound pattern should I use for reporting and analytics? Azure Synapse Link for Dataverse. It continuously exports to Synapse Analytics and Data Lake Storage and is designed for batch, analytics, business intelligence and machine learning scenarios. Event-driven patterns such as webhooks and plugins are the wrong shape for a destination that is a report.
Are webhooks a safe default for real-time outbound integration? Only where the receiving system can handle a high volume of messages. Microsoft states that qualifier explicitly, and it matters because a webhook makes the receiver’s throughput a dependency of your Dataverse write path. Posting to Service Bus or Event Hubs from a plugin decouples the two.
Cloud and enterprise architect with 17 years of experience across data platforms, integration and application development. Focus areas include Azure architecture, cloud-native application design, and ERP to data platform integration.