Dual-Write vs Virtual Tables: Which to Use for Dynamics 365 Finance and Operations Data (2026)

Last updated: November 6, 2026

By ZapAI Team

Dual-write copies finance and operations records into Dataverse and keeps both sides in sync, while virtual tables leave the data in Dynamics 365 Finance or Supply Chain Management and read it live. Our Dynamics 365 consulting team treats the choice as a question of record ownership, not features. As of November 2026, Microsoft supports both, calls them complementary, and has published no retirement date for dual-write.

Every F&O customer with a CRM side hits this fork. Sales wants customers. Field techs want stock levels. IT wants a Copilot Studio agent that can look up an open invoice. Pick wrong and you get a sync queue full of errors, or a slow form nobody can chart.

So this guide covers how each mechanism works, what Microsoft’s documentation says right now, how unified environments change setup, what each costs in Dataverse storage, and the decision rules we use with clients. Every product fact was checked against Microsoft Learn on November 6, 2026. Running Business Central? Different mechanism entirely, covered in our Business Central and Dynamics 365 Sales integration guide.

What Is the Difference Between Dual-Write and Virtual Tables?

Replication versus federation. Dual-write writes every change to both databases in near real time. Virtual tables store nothing in Dataverse and fetch rows from finance and operations each time someone asks.

Think of it this way. With dual-write, an account in Dynamics 365 Sales and a customer in Finance are two physical rows kept identical by a sync engine. With a virtual table, the Dataverse row is a window. Close it and nothing is left.

That single design difference drives everything else in this post, from storage cost to security to what breaks overnight, and it matters more than any feature list because it decides where your data physically lives. Both depend on the Power Platform integration. Both live inside Dataverse, so model-driven apps, canvas apps, Power Automate and Copilot Studio can use either. The similarities end there.

How Does Dual-Write Work?

It’s Microsoft’s out-of-box sync infrastructure. Once a table map runs, any create, update or delete in finance and operations writes to Dataverse, and any change in Dataverse writes back, inside the same transaction.

Two layers make it up, per Microsoft’s dual-write overview. The infrastructure layer handles synchronous, bidirectional data flow with play, pause and catch-up modes. The application layer is a set of Microsoft-built table maps for integrated customer master, vendor master, product mastering, prospect to cash and project to cash, and installing those packages adds company and party concepts to Dataverse, which is why your Sales accounts suddenly have a Company field.

Table maps, initial sync and live sync

A table map pairs a finance and operations entity with a Dataverse table, column by column. You turn each map on separately. Before it goes live, you either run an initial sync or skip it.

Initial sync has hard edges. Microsoft’s initial synchronization guidance lists them.

• 500,000 rows per run, per legal entity.
• A 24-hour timeout from Dataverse to finance and operations.
• Single-threaded tables like Customers V3 and Vendors V2 shouldn’t go from Dataverse to finance and operations above 70,000 rows.
• No initial sync from Dataverse for maps with 10 or more lookups.
• A five-minute export limit.
• Only five errors visible.
• Double quotes can fail it.

Above those numbers, Microsoft’s matrix says migrate data into each app separately, then activate the map and skip initial sync. And don’t activate maps until migration is done. Imports crawl otherwise.

Live sync has its own ceilings. Per the live synchronization limits page, one transaction from finance and operations to Dataverse can carry 1,000 records, and every transaction in either direction gets two minutes including Dataverse plugin time, after which it rolls back on both sides. Going the other way, the cap is a payload size, given as 116.85 MB in one place and 116.65 MB in another. Plan for the smaller.

Errors, queues and alerts

You get an activity log per map, initial sync error counts with a rerun option, and a catch-up errors tab for records that failed after a pause. Alerts can email admins or pause a map when an error threshold is hit.

Read the fine print on Microsoft’s error management page. The queue holds errored records for one day. Then it purges them. A failed customer update on Friday evening is gone by Monday unless someone retries it. Paused maps differ, since new requests queue and replay on resume.

Requirements and limits that rule it out

Some constraints aren’t tunable. The dual-write system requirements page lists them.

• Same Entra tenant and Azure datacenter.
• One finance and operations instance paired with one customer engagement instance.
• 40 legal entities for initial sync, 250 live.
• No cross-company data sharing.
• No distributed transactions.
• No trials or cloud-hosted environments.
• X++ code using doInsert, doUpdate or doDelete won’t trigger it.

Look twice at distributed transactions. Microsoft’s example is a canceled product receipt posting, where dual-write might create the receipt in Dataverse but not in Supply Chain Management. Sync isn’t consistency. If a business process can’t tolerate a record existing on one side only, even briefly, it needs a reconciliation report or an alert that someone actually reads every morning, in our experience.

How Do Virtual Tables for Finance and Operations Work?

Finance and operations acts as a virtual data source in Dataverse. Any public OData entity can be made visible as a virtual table with an mserp_ prefix, and every read or write becomes a live call, with nothing stored in Dataverse.

Under the hood, per Microsoft’s virtual entities overview, a Dataverse plugin translates the query and makes a secure service-to-service call that runs against the real entity. Entity logic runs. Form logic doesn’t. The calling user’s identity passes through, so finance and operations runs the query as that user, and when both apps sit in the same Azure region Microsoft expects the added overhead to stay under 30 milliseconds per call.

Enabling one is a checkbox. An admin opens the catalog called Available finance and operations entities, finds the entity, selects Visible and saves. Refresh pulls new metadata. Generated tables land in the managed MicrosoftOperationsERPVE package, and the prefix is fixed.

Limits you’ll feel in Dataverse

Virtual tables give up most features that need locally stored data. The general virtual table limitations include these.

• No auditing.
• No Dataverse search.
• No charts or dashboards.
• No queues or business process flows.
• No offline caching.
• No field-level security.
• No rollup columns.
• No sorting on virtual lookups.

Then come the practical ones. The finance and operations virtual entities FAQ says performance drops when a virtual table has relationships to other entities, so ask for a narrow column list. Several virtual tables joined to one Dataverse record can’t share a grid. The Data Integrator can’t read them. Disabled configuration keys can trigger paging errors. And in a plugin, the SYSTEM user can’t read finance and operations data.

Security is the part people get backwards. Every interactive user reading finance and operations data through a virtual table must also exist as a finance and operations user, and their ERP roles decide what they see. Good for control. Annoying for a Sales rep with no ERP login.

What Does Microsoft Recommend in 2026?

Microsoft frames the two as complementary. Its training guidance points to dual-write for near-real-time replication and offline needs, and to virtual tables for live access, large datasets and read-heavy work. We found no deprecation notice or feature freeze for dual-write on Microsoft Learn.

Clearest of all is Microsoft’s dual-write vs virtual tables training unit, which recommends dual-write for near-real-time sync, full offline capability or a tightly integrated replicated dataset, and virtual tables for real-time access without duplication, lower Dataverse storage on large datasets, and read-heavy scenarios with light CRUD. It says the decision “depends on the data ownership model, the need for replication, and offline requirements.” Sensible. Not prescriptive.

Plenty of partner blogs claim Microsoft now pushes virtual tables for all new work. We couldn’t find that on any Microsoft page. What the documentation shows is quieter.

• The system requirements page says future dual-write updates ship through One Version, with no plans to add regions.
• The newest entry on the dual-write what’s new page is an August 2025 security update that moved dual-write to a new app ID, live from September 10, 2025.
• The 2025 release wave 2 overview listed asynchronous operations in dual-write as upcoming GA, but that wave’s feature table doesn’t include it, and the plan is now archived, so the two pages disagree.
• Microsoft’s newest Field Service integration uses both.

Our read, labeled as opinion. Dual-write is maintained, not growing. New integration energy goes to the Power Platform integration, Link to Fabric and agent access through the Dynamics 365 ERP MCP server, whose data tools use OData, the same plumbing virtual tables sit on.

The Field Service example

Look at Microsoft’s own apps. The Field Service integration with finance and operations relies on dual-write maps for accounts, companies and products, then uses virtual tables for on-hand inventory views and for lookups to projects, line properties and locations. That page, updated November 3, 2026, says the integration won’t be available after February 28, 2027, as it moves to the Field Service and Project Operations integration. New installs already can’t turn it on.

So Redmond’s answer is both. Copy the masters. Read volatile data live. Our Project Operations guide covers the Integrated with ERP deployment, where dual-write maps carry project data to Finance.

How Do the Power Platform Integration and Unified Environments Change Setup?

Since May 1, 2025, every finance and operations environment must have the Power Platform integration enabled, linking it one-to-one with a Power Platform environment. Microsoft calls that link irreversible. Unified environments go further.

Consequences are spelled out on Microsoft’s Power Platform integration page. Unlinked environments were enabled automatically after the deadline. Disconnecting would mean data loss. Virtual tables configure themselves for the linked environment, though you can still set them up manually for extra Power Platform environments. Cloud-hosted development environments are deprecated for this integration, and Microsoft points developers to sandboxes or the unified developer environment instead.

Unified environments get their own admin overview, updated September 10, 2026. Finance and operations is now an application within Power Platform, installed through ERP templates or a provisioning app, alongside Sales, low-code apps and flows in one Dataverse environment that exposes two runtime URLs and needs at least 1 GB of both operations and Dataverse database capacity to provision.

Does one environment make dual-write obsolete? No. Microsoft doesn’t say that anywhere. Two databases still sit side by side, each with its own capacity line, and dual-write and virtual tables remain the documented ways to move or expose rows between them. One environment removes tenant and region guesswork. Not the design choice.

Where Does Dataverse Link to Fabric Fit?

Analytics, not apps. Link to Fabric keeps a read-only Delta Parquet replica of selected tables for Fabric and Power BI, and nothing writes back to finance and operations through it.

Confusion comes from the mserp_ prefix. Link to Fabric brings data entities in as mserp_ virtual tables, then replicates them for the lakehouse. Same names, different job. If a dashboard is the goal, skip dual-write maps, and don’t point Power BI at live virtual tables either, since Microsoft’s integration guidance says not to use OData for Power BI reports. Our Dataverse Link to Fabric guide covers setup, entity change tracking and storage math.

What Do They Cost in Dataverse Storage and Licensing?

Storage is where they split hardest. Dual-write consumes Dataverse database capacity, because every synced row exists twice. Virtual tables consume none for the data itself.

Start with what you get. Buying any finance and operations license adds 10 GB of Dataverse database capacity to the tenant, plus an increment per user license, per the integration page. Adding Dataverse to a linked environment takes 3 GB or more on its own. Add-on sandboxes bring none. Past your quota, the Power Apps pricing page lists database capacity at $40 per GB per month, paid yearly.

Run your own numbers. Microsoft publishes no per-row figure. Customers, contacts, addresses and released products with variants add up fast in a distribution business, and every sandbox copied from production with dual-write running carries its own set. A simple way to picture it is that every table you dual-write becomes a permanent line on your capacity report, in production and in every sandbox holding a copy, while a virtual table adds only its metadata.

Licensing is murkier. Microsoft’s virtual entities FAQ is clear that interactive users need a finance and operations account, but which license that account needs depends on what the user does, which makes it a Licensing Guide question rather than a technical one. Our Dynamics 365 Finance licensing guide covers roles and attach rules. Confirm before designing a virtual table app for 300 Sales users.

Dual-Write vs Virtual Tables, Side by Side

Dual-write wins on offline use, Dataverse features and local speed. Virtual tables win on storage, setup and one source of truth. Neither suits analytics.

Which Should You Use? Decision Rules by Scenario

Ask two questions. Who owns the record? Does Dataverse need it when finance and operations doesn’t answer? Shared ownership or offline need points to dual-write, and ERP ownership with live-only need points to virtual tables.

These are ZapAI practice rules, not Microsoft rules. Each traces to a documented limit.

• Sales creates prospects that become customers in Finance. Dual-write customers, contacts and addresses.
• Field technicians work in basements with no signal. Dual-write whatever must open offline.
• Customer Service agents need open invoices or credit limits. Virtual tables, read only, which our Customer Service consultants tend to surface as a subgrid on the account form so agents never leave the case they’re working on.
• A sales rep checks stock before quoting. Virtual tables, as Field Service does.
• A process posts thousands of records in one X++ transaction. Keep it off dual-write, or split it into batches under 1,000 records, before the two-minute limit rolls everything back on both sides.
• Managers want charts inside a model-driven app. Dual-write, or report in Fabric.
• Auditors need Dataverse audit history. Dual-write.
• A Copilot Studio agent needs live ERP facts. Virtual tables or the Dynamics 365 ERP MCP server, which works within the agent’s security role, rather than a copy that can drift, and our Dataverse MCP server guide covers the Dataverse side of that build.
• ERP and CRM sit in different tenants. Neither works, so plan OData or Azure-hosted integration from our Azure integration patterns guide.
• Reporting is the only goal. Use Link to Fabric.

One more rule we apply without exception. Don’t dual-write a table just because a Microsoft map exists for it, because every map you switch on is a map you’ll monitor, upgrade and troubleshoot for years, and each one adds rows to your Dataverse bill. Start small. Expose the rest as virtual tables. Our Dynamics 365 Sales consultants and Field Service consultants scope it that way.

How Do You Implement Each One Without Surprises?

For dual-write, migrate data first, choose initial sync per table, assign security roles and set alerts before go-live. For virtual tables, make entities visible, create ERP users and test with real roles.

Dual-write steps

1. Confirm the integration, tenant and datacenter.
2. Install current dual-write packages, at or above the minimums Microsoft set in its app ID migration notice, 3.5.1.135 for party and global address book and 2.3.4.265 for supply chain extended.
3. Link environments and pick legal entities.
4. Migrate data, then activate maps.
5. Choose initial sync or skip per table.
6. Assign Dual-Write Runtime User and Dual-Write App User roles.
7. Create alerts, then restart maps.
8. Rehearse a pause and resume.

Where dual-write projects break

In our work, five failures repeat. Custom plugins that push transactions past two minutes. Batch jobs writing over 1,000 records at once. Initial syncs started mid-migration. Customizations keyed to the old app ID, which Microsoft warned would show a different integration user in the CreatedBy and ModifiedBy audit fields for every record touched on or after September 10, 2025. And errored records left past the one-day purge, which means silent data gaps.

Virtual table steps and failure points

1. Confirm the linked environment.
2. Check the entity is public in OData, then make it visible.
3. Reference it from your own package with Add existing.
4. Create ERP users with scoped roles.
5. Keep views narrow.
6. Test plugins as a real user.

Virtual table failures look different. Slow forms from lookup-heavy views. Paging errors from configuration keys. Empty grids because nobody created the user’s ERP account. Fixable. Predictable.

Checklist Before You Commit

Ten checks settle most designs before anyone builds a map. Run them per table.

• Name the system of record.
• Mark tables both sides edit.
• List tables offline users need.
• Flag audit, search or chart needs.
• Count rows and legal entities against the 500,000, 70,000, 40 and 250 limits.
• Find X++ processes writing over 1,000 records per transaction.
• Confirm tenant, datacenter and integration status.
• Estimate Dataverse storage, sandboxes included.
• Decide who needs an ERP account.
• Route reporting to Fabric.

Want a second pair of eyes on the table list? Our Dataverse services team runs this checklist with ERP and CRM leads in the same room, which is where most of the answers live.

What Could Change After Ignite 2026?

Possibly something. Ignite runs November 17 to 20, 2026, in San Francisco. Expect a refresh of this post by late November.

We’ll watch three things, namely whether asynchronous dual-write resurfaces on the AI at Work roadmap that replaced release plans in 2026, whether Microsoft publishes any formal position on dual-write for new projects, and whether the ERP MCP server gains features that make virtual tables less central for agents. Until then, treat the documented limits above as current.

Wrapping Up

Short version. Dual-write copies shared masters into Dataverse and keeps both sides editable, at the cost of storage, monitoring and hard transaction limits. Virtual tables leave data where it lives and enforce ERP security, but give up offline, audit, search and charts. Microsoft uses both inside its own apps. So should you, table by table.

ZapAI is a Microsoft Dynamics 365, Power Platform, Fabric and AI consulting firm in Irving, Texas, working with businesses across Dallas-Fort Worth and nationwide. Our Dynamics 365 Finance consultants design dual-write maps, virtual table apps and the security behind them. Planning a CRM rollout on top of Finance or Supply Chain Management? Book a dual-write and virtual table design review, and we’ll sort your tables into copy, read live or report before anything gets built.

Questions Teams Ask About Dual-Write and Virtual Tables

Is Microsoft deprecating dual-write?

Can we use dual-write and virtual tables together?

Do virtual tables use Dataverse storage?

Does every user need a finance and operations account for virtual tables?

How fast is dual-write?

Does dual-write work with Business Central?

Should we report on finance and operations data through dual-write or virtual tables?