Dual Write & Virtual Entities in Dynamics 365: The Complete Guide (2026)

What is Dual Write?

Dual write is a Microsoft-managed integration framework that creates a living synchronization bridge between Dynamics 365 Finance & Operations (F&O) and Microsoft Dataverse. When a customer record is created or modified in F&O, dual write automatically propagates that change to Dataverse in near-real-time, and vice versa. This bidirectional, event-driven sync eliminates manual ETL processes and keeps multiple systems in agreement without custom code.

At its core, dual write solves a critical business problem: how to maintain single source of truth across disconnected systems. For organizations running both Dynamics 365 ERP (F&O) and customer engagement tools (model-driven apps, Power Apps, etc.) on Dataverse, dual write is the Microsoft-native answer to data silos.

Dual Write vs Virtual Entities: Core Differences

Dual write and virtual entities are complementary—not competing—technologies, but they serve fundamentally different use cases:

• Dual Write: Copies data from F&O to Dataverse (and optionally back). Data lives in both systems. Enables offline-first Dataverse workflows, cascading business logic, and real-time reporting.
• Virtual Entities: Proxies that let Dataverse query F&O data on-demand via OData. No data copying; only read access. Dataverse never persists the data—each query hits F&O’s OData endpoint.

The decision hinges on your architecture: use dual write when you need Dataverse to own the data locally and react to it; use virtual entities when F&O is the system of record and Dataverse should reference it without copying.

How Dual Write Works: Architecture & Components

Dual write operates through a sophisticated infrastructure:

1. Table Maps

A table map defines which F&O table syncs to which Dataverse table, including column mappings, filtering rules, and sync direction. Microsoft provides 50+ pre-built maps for standard entities like Customers, Vendors, Products, and Sales Orders. Custom maps are created via the Admin Portal, REST API, or Power Apps UI.

2. Initial Sync

When you activate a table map for the first time, dual write bootstraps the Dataverse table with existing F&O records. This one-time bulk operation can take minutes for small tables (under 10K records) or hours for large ones. A known limitation: initial sync may stall or underperform with 100K+ records, particularly if source data has complex filtering or transformation logic. Stagger large maps or enable async mode (2025 Wave 2+) to avoid blocking the integration environment.

3. Live Sync

After initial sync, every create, update, or delete in F&O triggers a dual-write event. The event is queued, transformed according to column mappings, and written to Dataverse. Round-trip latency is typically sub-second under normal load, but can increase during peak transaction volumes. Each event is atomic—if the Dataverse write fails, the event moves to a dead-letter queue for manual resolution.

4. Error Handling & Dead-Letter Queues

When a sync event fails (validation error, mapping issue, security constraint, API throttling), dual write stores it in a dead-letter queue visible in the Admin Portal. Operators can review, edit, and replay failed events. Common failure scenarios include constraint violations, business rule breaches, or temporary API unavailability. The Admin Portal provides dashboards to monitor queue depth, failure rates, and latency percentiles.

5. Conflict Resolution

Bidirectional maps can create conflicts: a customer name is edited in F&O and simultaneously in Dataverse. Dual write uses last-write-wins semantics by default, with timestamps to determine which change prevails. For critical tables, consider unidirectional maps or application-layer business logic to prevent conflicts.

2025 Release Wave 2 Update: Asynchronous Dual Write

Microsoft released asynchronous dual write in late 2025 to address high-transaction scenarios. The key difference: write operations to Dataverse are fire-and-forget. The F&O transaction commits immediately without waiting for Dataverse confirmation, and the sync event is processed asynchronously by background services.

Benefits of Async Dual Write

• Decoupled Performance: F&O writes are no longer blocked by Dataverse API latency or throttling.
• Higher Throughput: Process thousands of events per minute without F&O impact.
• Resilience: Temporary Dataverse outages don’t block F&O transactions.

Trade-offs

• Eventual Consistency: Dataverse data is not immediately up-to-date; expect 100ms–5s latency in normal conditions, longer during heavy load.
• Complexity: Dataverse workflows and plugins must handle eventual consistency—they cannot assume data synchronization is complete immediately.
• Debugging: Asynchronous failures are harder to debug; event tracing and dead-letter queue inspection are essential.

When to Use Async Dual Write

Enable asynchronous mode if your transaction volume exceeds ~1,000 operations/minute in F&O, or if F&O-Dataverse sync latency is impacting performance. Leave synchronous for lower-volume integrations or scenarios where immediate consistency is critical (e.g., critical validations or cascading business logic).

Virtual Entities: On-Demand Data Access

Virtual entities are a lightweight alternative to dual write. Instead of copying F&O data to Dataverse, a virtual entity in Dataverse is a proxy that queries F&O’s OData API on-demand. When you retrieve a virtual customer record in Dataverse, the query is translated to an OData call to F&O, and the result is returned.

How Virtual Entities Work

A virtual entity table is configured to point to an F&O OData endpoint and a specific entity (e.g., CustTable for customers). Dataverse maintains metadata about the F&O schema but stores no data. Queries to the virtual table are intercepted, converted to OData filters, and sent to F&O’s REST API. Results are materialized in memory and returned to the caller.

Limitations & Considerations

• Read-Only: Virtual entities are not writable by default. Create, update, or delete operations require custom plugins or flow logic that calls F&O’s API separately.
• API Throttling: Each query consumes F&O API credits. High-volume reads can hit throttling limits (typically 6,000 requests/minute per tenant).
• Latency: Network round-trips to F&O introduce 200–1,000ms latency per query. Bulk operations or power queries may time out.
• Filtering Complexity: Not all F&O OData filters translate cleanly to Dataverse query syntax; complex where clauses may fail silently or return unexpected results.
• Offline Unavailable: Virtual entities require live connectivity to F&O; they cannot be used in offline Dataverse scenarios.

Virtual Entities vs Dual Write: Decision Matrix

Criterion	Dual Write	Virtual Entity
Data Location	Copied to Dataverse	Remains in F&O (queried on-demand)
Write Support	Bidirectional or unidirectional	Read-only (with custom logic for writes)
Latency	Sub-second to minutes (async)	200–1,000ms per query
Offline Access	Yes (Dataverse caches locally)	No (requires F&O connectivity)
API Throttling	Minimal (initial sync only)	Per-query (high-volume risk)
Business Logic Execution	Dataverse plugins/flows can react immediately	F&O rules apply; Dataverse logic sees cached data
Storage Cost	Higher (duplicate data in Dataverse)	Lower (no Dataverse storage)
Best For	Real-time workflows, offline-first apps, Dataverse-centric logic	Lightweight lookups, reference-only data, F&O system of record

Key Table Maps & Common Scenarios

Microsoft provides pre-built maps for high-velocity tables:

Customers (CustTable ↔ Accounts)

F&O customer records sync to Dataverse accounts. Includes address, contact info, payment terms, credit limit. Bidirectional sync allows Dataverse to create/update accounts, which feed back to F&O. Common customization: filter by customer group or company.

Vendors (VendTable ↔ Accounts)

Vendor data syncs similarly to customers, enabling procurement teams to manage vendors in model-driven apps.

Products (InventTable ↔ Products)

Product master data syncs from F&O to Dataverse. Typically unidirectional (F&O is source of truth). Includes pricing, dimensions, and categorization. Virtual entities are often preferred here to avoid data duplication.

Sales Orders (SalesTable ↔ Orders)

Order headers sync in near-real-time. Enables Dataverse to display live order status, trigger fulfillment workflows, or push custom data back to F&O for special handling.

Invoices (CustInvoiceTable ↔ Invoices)

Invoice records sync for billing integration, revenue recognition workflows, or customer self-service portals in model-driven apps.

Setup & Configuration Requirements

Prerequisites

• Dual-write enabled in F&O tenant settings (Power Platform Integration tab).
• Linked Dataverse environment (established via Power Platform Admin Center).
• Appropriate security roles in both systems (Dynamics 365 System Administrator for F&O, System Customizer for Dataverse).
• Microsoft Dataverse for Teams or a premium Dataverse environment (Teams plans have limitations).

Configuration Steps

1. Link Environments: In F&O, navigate to Power Platform Integration settings and link the Dataverse environment. This establishes trust and enables bidirectional communication.
2. Import Solutions: Import the dual-write orchestration solution into Dataverse from the Microsoft AppSource.
3. Create or Activate Table Maps: Use the Dual-Write Admin Portal (app.powerplatform.microsoft.com) to create custom maps or activate pre-built ones.
4. Configure Column Mappings: For each table map, define which F&O columns map to Dataverse columns, including transformations or default values.
5. Set Sync Direction: Choose unidirectional (F&O → Dataverse or vice versa) or bidirectional.
6. Run Initial Sync: Execute the initial sync to bootstrap Dataverse with existing F&O data. Monitor progress in the Admin Portal.
7. Test & Validate: Create a test record in F&O, confirm it appears in Dataverse, modify it in Dataverse, and verify the round-trip.
8. Enable Production: Once validated, enable the map for production workloads.

Business Events & Data Events: Event-Driven Alternatives

Dual write is not the only way to achieve F&O-Dataverse integration. Business events and data events offer more granular, event-driven alternatives:

Business Events

F&O publishes domain events (e.g., “Customer Created,” “Sales Order Confirmed”) to an event hub. External systems subscribe and react. Business events are coarse-grained and designed for high-volume, loose coupling.

Data Events

Dataverse publishes change notifications (created, updated, deleted) for any table. Power Automate flows or custom plugins react in real-time. Data events are fine-grained and immediate.

When to Use Events Instead of Dual Write

• Selective synchronization (only specific fields or filtered records).
• Complex transformations that don’t fit table map logic.
• Integration with systems other than Dataverse (e.g., Azure Service Bus, Power BI).
• Scenarios where F&O data is not meant to be replicated, only observed.

Performance Considerations & Tuning

Transaction Volume & Throughput

Dual write is designed for high-volume, mission-critical data sync. Typical throughput is 1,000–5,000 operations/minute in synchronous mode, and 5,000–20,000+ in asynchronous mode. Performance degrades under these conditions:

• Dataverse is throttled or experiencing latency.
• Large field sizes or complex transformations slow column mapping.
• Bidirectional maps create circular sync loops.
• Initial sync of 100K+ records stalls due to API limits.

Async vs Sync Trade-offs

Use synchronous dual write for low-volume tables or scenarios requiring immediate consistency. Switch to asynchronous (Wave 2 2025+) for high-volume, performance-critical tables. Be prepared to handle eventual consistency in Dataverse logic.

Monitoring & Alerting

Enable monitoring dashboards in the Dual-Write Admin Portal. Track:

• Sync latency (p50, p95, p99 percentiles).
• Dead-letter queue depth and failure rate.
• Initial sync completion status and estimated time remaining.
• API throttling and timeout incidents.

Common Challenges & Solutions

Initial Sync Stalls or Fails

Cause: Large table (100K+ records) or complex filtering exceeds API quotas.
Solution: Break into smaller maps by company or date range, enable async dual write, or use virtual entities for reference data.

Circular Sync Loops

Cause: Bidirectional map where F&O and Dataverse plugins trigger each other endlessly.
Solution: Switch to unidirectional map or add guard logic in plugins to detect and break cycles.

Conflict Resolution Failures

Cause: Same record modified in both systems simultaneously; last-write-wins produces unexpected result.
Solution: Use unidirectional maps for system-of-record tables, implement application-layer conflict resolution, or add business rules to prevent conflicting edits.

Dataverse Storage Bloat

Cause: Copying large F&O tables to Dataverse exhausts storage allocations.
Solution: Use virtual entities for read-heavy reference data, or implement archival/purge policies in Dataverse.

Throttling & Rate Limits

Cause: Dual write or virtual entity queries exceed API rate limits.
Solution: Enable async dual write, batch operations, or implement retry logic with exponential backoff.

Best Practices & Microsoft Guidance

Design & Architecture

• Map only tables that need to be in Dataverse; avoid copying unnecessary data.
• Choose unidirectional maps unless truly bidirectional sync is required; reduces complexity and conflicts.
• Use virtual entities for lookup/reference tables (products, customers) that F&O owns exclusively.
• Plan for eventual consistency in asynchronous scenarios; Dataverse logic should not assume immediate sync completion.

Testing & Validation

• Test initial sync in a sandbox environment with production-like data volume.
• Verify round-trip sync (F&O → Dataverse → F&O) for bidirectional maps.
• Load test with production transaction volumes to identify throttling or performance issues.
• Test error scenarios: fail Dataverse API calls, trigger validation errors, and verify dead-letter queue handling.

Customization & Extensions

• Avoid deep customization of dual-write table maps; Microsoft updates these frequently.
• Use column mappings for simple transformations; for complex logic, implement F&O plugins or Dataverse flows.
• Document all customizations and keep them in version control.
• Regularly review Microsoft’s release notes for dual-write updates and breaking changes.

Monitoring & Maintenance

• Implement automated monitoring for dead-letter queue depth and failure rates.
• Schedule weekly reviews of sync logs and performance metrics.
• Establish an incident response process for high failure rates or sync stalls.
• Document known issues and workarounds; maintain a runbook for troubleshooting common problems.

When NOT to Use Dual Write (And What to Use Instead)

Scenario: Read-Only Lookup Data

Problem: You need Dataverse forms to show F&O customer names and addresses, but never update them.
Better Solution: Use virtual entities. No data copying, lower storage cost, always fresh data from F&O.

Scenario: One-Time Data Migration

Problem: You need to move historical customer data from F&O to Dataverse once, not continuously.
Better Solution: Use a scheduled Synapse/Power Query pipeline or manual SQL export-import. Dual write is overkill for one-time operations.

Scenario: Selective Field Sync

Problem: You want to sync only customer name and ID, excluding sensitive financial fields.
Better Solution: Implement a Dataverse plugin that calls F&O’s API on-demand, or use data events with Power Automate for fine-grained control.

Scenario: Complex Custom Transformations

Problem: F&O customer data requires heavy transformation (combine fields, format addresses, enrich with external data) before landing in Dataverse.
Better Solution: Use a Power Automate flow triggered by F&O business events or Dataverse change notifications. Dual-write column mappings are limited to simple transformations.

Scenario: Offline-First Mobile Apps

Problem: You need Dataverse data on mobile devices that lose connectivity intermittently.
Solution: Dual write + offline-enabled model-driven apps. Dual write syncs data to Dataverse, which the mobile app caches and syncs when connected.

Future Outlook: 2026 & Beyond

Microsoft continues to invest in dual write and virtual entities. Expected directions:

• Improved Async Performance: Further optimizations to asynchronous dual write to reduce eventual consistency latency.
• Virtual Entity Enhancements: Better OData filter translation and write support.
• AI-Driven Conflict Resolution: Machine learning models to intelligently resolve sync conflicts.
• Broader ERP Support: Dual-write extensions to cloud-native ERP alternatives (not just F&O).

Summary & Key Takeaways

Dual write and virtual entities are complementary technologies for bridging F&O and Dataverse. Dual write is ideal for scenarios requiring local data ownership, real-time workflows, and bidirectional sync; virtual entities excel for lightweight, read-only lookups where F&O is the system of record. The 2025 Wave 2 asynchronous dual-write release shifts the paradigm toward eventual consistency and decoupled performance, enabling higher transaction volumes but requiring more sophisticated error handling and monitoring. Choose based on your consistency requirements, data ownership model, and transaction volume—and don’t overlook business events and Power Automate flows as alternatives for selective or transformation-heavy scenarios.