15.1 Dual-Write & Virtual Entities

15.1 Dual-Write & Virtual Entities

Quick Answer: Microsoft provides two complementary integration architectures to connect Dynamics 365 Finance and Operations with Microsoft Dataverse: Dual-write and Virtual Entities. Dual-write is a bidirectional, near-real-time data replication engine that persists data physically in both F&O and Dataverse databases, making it ideal for continuous cross-app business processes (e.g., Prospect-to-Cash) that require offline mobile support and independent transactional speed. Virtual Entities are a zero-replication, direct-query abstraction that projects public F&O data entities as native Dataverse tables (mserp_*), executing real-time CRUD operations against the F&O OData v4 runtime without consuming Dataverse database storage.

---

1. Microsoft Dataverse Integration Landscape

Modern enterprise architectures frequently pair Dynamics 365 Finance and Operations (F&O) with the Microsoft Power Platform and customer engagement apps (Dynamics 365 Sales, Customer Service, Field Service). Historically, synchronizing data across these platforms required custom ETL pipelines, batch integrations using the Data Management Framework (DMF), or point-to-point middleware. Today, Microsoft provides two native, turnkey integration architectures built directly into the platform core:

Microsoft Dataverse Integration Paradigms

┌─────────────────────────────────────────────────────────────────────────────┐
│                               Dual-Write                                    │
│  • Replicated Architecture (Physical data copies in both F&O and Dataverse) │
│  • Near-real-time bidirectional sync (Tightly coupled via transactional hooks)│
│  • Offline client support, high-frequency local queries                     │
│  • Incurs Dataverse database storage consumption                            │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│                            Virtual Entities                                 │
│  • Virtualized Architecture (Zero data replication, pure pass-through query)│
│  • Direct OData v4 calls executed live against F&O runtime                   │
│  • Zero Dataverse storage consumption for table data                        │
│  • Real-time data freshness, no sync lag or catch-up queuing                │
└─────────────────────────────────────────────────────────────────────────────┘

Selecting between Dual-write and Virtual Entities is one of the most heavily tested competency areas on the MB-500 exam. Developers must recognize when business requirements demand physical data presence versus real-time on-demand querying.

---

2. Dual-Write: Architecture, Mapping & Execution

Dual-write is an out-of-the-box infrastructure that provides tightly coupled, near-real-time, bidirectional communication between Finance and Operations apps and Microsoft Dataverse. Whenever a user or process creates, updates, or deletes a record in one system, that change is immediately propagated to the other.

Core Technical Architecture

Dual-write operates through pre-built AppSource solution packages deployed in both environments:

1. F&O Dual-Write Framework: Integrated into the Application Object Server (AOS). It intercepts database transactions using table data entity events and pushes changes via secure HTTPS endpoints to Dataverse.
2. Dataverse Dual-Write Solutions: Solutions such as DualWriteEntityCore, DualWriteFinanceAndOperationsMapping, and DualWriteSupplyChainMapping install metadata, entity maps, and underlying Common Data Model (CDM) tables into the Dataverse environment.

Dual-Write Bidirectional Runtime Flow

┌───────────────────────────────┐               ┌───────────────────────────────┐
│   Dynamics 365 F&O (AOS)      │               │      Microsoft Dataverse      │
│                               │               │                               │
│   CustTable / CustCustomerV3  │               │   account Table (CDM)         │
│   ┌───────────────────────┐   │  HTTPS Push   │   ┌───────────────────────┐   │
│   │ Pre/Post Trans Hooks  │───┼──────────────>│   │ DualWrite Core Plugin │   │
│   └───────────────────────┘   │               │   └───────────────────────┘   │
│               ▲               │               │               │               │
│               │   HTTPS Push  │               │               ▼               │
│               └───────────────┼───────────────┼─── Database Mutation (Commit) │
│   Database Mutation (Commit)  │               │                               │
└───────────────────────────────┘               └───────────────────────────────┘

Table Maps & Field Mappings

Data flows between F&O and Dataverse through Table Maps. Each table map pairs a specific F&O Data Entity (e.g., CustCustomerV3Entity) with a target Dataverse table (e.g., account).

Inside a table map, developers configure Field Mappings using three primary transformation techniques:

• Direct Mapping: Direct 1-to-1 attribute binding (e.g., F&O CustomerAccount to Dataverse accountnumber).
• Value Mapping (Lookup / Enums): Transforms enumerated values or lookup codes between systems (e.g., mapping F&O customer group 10 to Dataverse option set integer 100000001).
• Transformation Rules & Concatenation: Applies expressions to format, concatenate, or truncate values (e.g., combining FirstName and LastName into fullname, or setting default fallback values if an optional source field is null).

Initial Synchronization vs. Live Sync

Dual-write execution operates in two distinct operational phases:

[!IMPORTANT] Critical Exam Concept: Company Context & cdm_company Microsoft Dataverse is fundamentally a global, multi-tenant database without native company partitions, whereas Dynamics 365 Finance and Operations data entities are strictly partitioned by legal entity (DataAreaId). Dual-write bridges this architectural difference using the cdm_company table in Dataverse. Every synchronized Dataverse record that represents legal-entity-specific data contains a lookup reference to the cdm_company table. If the company relationship is unmapped or invalid, Dual-write rejects the transaction.

Disconnection & Catch-Up Mode

In enterprise operations, network outages, maintenance windows, or service restarts can temporarily sever connectivity between F&O and Dataverse. Dual-write handles connection loss through automated state management:

1. Error Detection: When live sync fails to deliver a transaction across the boundary, the table map triggers an alert and evaluates the error threshold.
2. Catch-Up / Paused State: The table map transitions to Paused state. Instead of terminating user business processes or throwing unhandled database exceptions, F&O diverts outgoing mutations into an internal queue (DualWriteCatchUpQueue).
3. Catch-Up Execution: Once connectivity is restored, administrators or automated health services click Resume. The Dual-write engine replays the queued transactions sequentially in the exact order they were committed, restoring transactional consistency between systems.

---

3. Virtual Entities: Zero-Replication Direct Query

Virtual Entities (also known as Virtual Tables) provide a completely different architectural pattern: they create a real-time, zero-footprint window into F&O data directly from Microsoft Dataverse without replicating records.

Virtual Entity Direct Query Execution Pipeline

┌─────────────────────────────────────────────────────────────┐
│                     Power Platform Client                   │
│         (Model-Driven App / Canvas App Power Fx / OData)    │
└──────────────────────────────┬──────────────────────────────┘
                               │ Live Query (e.g., Get Customers)
                               ▼
┌─────────────────────────────────────────────────────────────┐
│                  Microsoft Dataverse Engine                 │
│  • Virtual Table Schema: mserp_custcustomerv3entity         │
│  • Zero physical records stored in Dataverse SQL storage   │
│  • Custom Dataverse VE Data Provider Plugin                 │
└──────────────────────────────┬──────────────────────────────┘
                               │ Translates to OData v4 Request
                               ▼
┌─────────────────────────────────────────────────────────────┐
│            Dynamics 365 Finance and Operations              │
│  • Public Data Entity: CustCustomerV3Entity (IsPublic=Yes)   │
│  • OData Endpoint: /data/CustomersV3                        │
│  • Executes real-time SQL queries and X++ business logic    │
└─────────────────────────────────────────────────────────────┘

How Virtual Entities Work

When a user or application queries a Virtual Entity in Dataverse:

1. The Power Platform client issues a query against a table named with the mserp_ prefix (e.g., mserp_custcustomerv3entity).
2. The Dataverse Virtual Entity Data Provider intercepts the call.
3. The provider constructs a secure OData v4 HTTP request authenticated via Microsoft Entra ID and calls the Dynamics 365 F&O OData endpoint.
4. F&O processes the request against the underlying data entity, executing standard X++ security, permissions, and query logic.
5. F&O returns the JSON payload to Dataverse, which transforms it into standard Dataverse entity collections on the fly.

Installing and Configuring Virtual Entities

Enabling Virtual Entities requires a specific administrative configuration path:

1. Deploy Solution Package: Install the Dynamics 365 Virtual Entity solution into the target Dataverse environment via Microsoft AppSource or the Power Platform admin center.
2. Register Entra ID App: In the Azure Portal, create a Microsoft Entra ID Application Registration for Dataverse-to-F&O communication, granting delegated or application permissions to the Dynamics ERP API.
3. Configure Virtual Entity Data Source: In Dataverse, navigate to Advanced Settings > Administration > Virtual Entity Data Sources, open the Finance and Operations data source, and configure:
   • Target URL: The root F&O environment URL (e.g., https://contoso.operations.dynamics.com).
   • OAuth Application ID: The Client ID of the Entra ID registration.
   • OAuth Secret: The client secret.
   • AAD Resource: The F&O root URL.
4. Make Entities Visible: In Dataverse, open Advanced Find and select the table named Available Finance and Operations Entities (mserp_virtualentityconfigurations). Search for the target F&O public data entity, open its record, and toggle Visible = Yes.
5. Metadata Generation: Once saved, Dataverse automatically queries F&O metadata and dynamically generates the native Dataverse virtual table schema (mserp_<entityname>), including all fields, keys, and data types.

CRUD Operations Over Virtual Entities

Virtual Entities support full Create, Read, Update, and Delete (CRUD) operations directly against F&O runtime data:

• Read: Executes live $filter, $select, and $top queries against F&O OData endpoints.
• Write (Create / Update / Delete): The Dataverse engine translates mutations into OData POST, PATCH, or DELETE verbs. In F&O, these calls trigger entity methods including insert(), update(), delete(), and critical validation methods such as validateWrite() and validateField().

[!CAUTION] Virtual Entity Prerequisites & Limitations

• IsPublic = Yes: Only F&O data entities with IsPublic = Yes and a valid PublicCollectionName / PublicEntityName can be exposed as Virtual Entities.
• Primary Key Requirement: The data entity must have a well-defined primary key. If the key comprises multiple fields, Dataverse composites them into a single string GUID or hash.
• No Offline Storage: Virtual Entities cannot be cached in Dataverse mobile offline profiles. Users must have continuous internet connectivity to access virtual table data.
• Performance Overhead: High-frequency, large-volume queries against Virtual Entities directly consume F&O OData throttling limits and AOS CPU threads.

---

4. Comprehensive Comparison & Architectural Decision Matrix

Choosing between Dual-write and Virtual Entities represents a classic architectural trade-off between data replication (high local performance, offline support) and data virtualization (zero storage footprint, real-time accuracy).

---

5. Scenario Walk-Through: Multi-System Architecture Implementation

Business Context

Contoso Enterprise manufactures industrial machinery. They utilize Dynamics 365 Finance and Operations for ERP and Dynamics 365 Sales for customer relationship management. The architecture board establishes two business requirements:

1. Requirement A (Customer & Contact Master): Sales representatives must access customer account data in the field using the mobile Power App with full offline capabilities. Sales reps must be able to create new customers in Dataverse that immediately replicate into F&O.
2. Requirement B (Inventory On-Hand & Price Checking): Field technicians in the customer service portal need to inspect real-time warehouse inventory on-hand balances across 200 distribution centers. The inventory data changes thousands of times per minute across the global supply chain, and replicating these millions of rows into Dataverse would exceed storage budgets.

Architectural Solution & Configuration

Contoso Multi-System Integration Topology

┌─────────────────────────────────────────────────────────────────────────────┐
│                     Dynamics 365 Sales / Power Apps                         │
│                                                                             │
│   Customer Form (Offline Supported)           Inventory Inquiry Screen      │
│   Table: account                              Table: mserp_inventitemonhand │
└──────────────────────┬──────────────────────────────────────▲───────────────┘
                       │                                      │
          Dual-Write   │ Replication             Direct Live  │ Virtual Entity
          Live Sync    │ (Physical Sync)         OData Query  │ (Zero Storage)
                       ▼                                      │
┌─────────────────────────────────────────────────────────────┴───────────────┐
│                   Dynamics 365 Finance and Operations                       │
│                                                                             │
│   CustCustomerV3Entity                        InventItemOnHandEntity        │
│   (Physical F&O Database)                     (Physical F&O Database)       │
└─────────────────────────────────────────────────────────────┘

Implementation of Requirement A (Dual-Write for Customers)

1. Navigate to Data management > Dual-write in Dynamics 365 F&O.
2. Select the Customers V3 (accounts) table map (CustCustomerV3Entity <-> account).
3. Review field mappings: verify CustomerAccount maps to accountnumber, Name maps to name, and OrganizationType is mapped via value transformation.
4. Click Run to launch the Initial Sync wizard. Designate Dynamics 365 Finance and Operations as Master to overwrite any unlinked draft records in Dataverse with master financial accounts.
5. Enable live sync. Test by creating a customer in the Dataverse Model-Driven app; observe immediate record creation in F&O with the correct cdm_company assignment.

Implementation of Requirement B (Virtual Entity for On-Hand Inventory)

1. Confirm the F&O data entity InventItemOnHandEntity has property IsPublic = Yes and PublicCollectionName = InventItemOnHand.
2. Open the Dataverse environment, launch Advanced Find, and query table Available Finance and Operations Entities (mserp_virtualentityconfigurations).
3. Locate the row with mserp_entityname = InventItemOnHandEntity.
4. Edit the record, check the box Visible = Yes, and click Save.
5. Navigate to the Power Apps maker portal (make.powerapps.com). Verify that a new native Dataverse table named mserp_inventitemonhandentity appears in the Dataverse table catalog.
6. Add a subgrid to the Service Portal form binding directly to mserp_inventitemonhandentity. When technicians open the portal, live queries fetch real-time stock balances directly from F&O with zero storage overhead in Dataverse.

---

6. Real-World Exam Traps: Dual-Write & Virtual Entities

[!WARNING] Exam Trap 1: The Virtual Entity Offline Fallacy A classic MB-500 exam scenario describes mobile field technicians who travel to remote basements or flight hangars with no cellular connectivity and asks whether Virtual Entities can be configured for offline caching. The answer is strictly NO. Virtual Entities are real-time OData pass-through proxies and cannot be registered in Power Apps mobile offline profiles. If offline capabilities are required, Dual-write or native Dataverse tables with scheduled synchronization must be utilized.

[!WARNING] Exam Trap 2: Company Context & The cdm_company Foreign Key Trap Microsoft Dataverse has a flat, global schema without legal entity partitions, whereas Finance and Operations strictly enforces DataAreaId scoping on transactions. On the exam, questions often test why a Dual-write record creation in Dataverse fails to sync to F&O. The culprit is almost always a missing or invalid lookup to the cdm_company table in Dataverse. Every legal-entity-bound Dataverse record must explicitly reference its corresponding cdm_company row.

[!WARNING] Exam Trap 3: Initial Sync Conflict Resolution Direction When configuring Dual-write for existing environments, candidates often mistake live sync conflict behavior for initial sync conflict behavior. In Initial Sync, you must designate a master system (F&O or Dataverse) upfront; the master system unconditionally overwrites matching records in the secondary system. In Live Sync, mutations are validated on-the-fly by receiving business logic, and transactional rollbacks or queue pauses occur if business rules fail.

[!WARNING] Exam Trap 4: The IsPublic and Public Collection Name Requirement If an exam question asks why a custom F&O data entity does not show up in Dataverse's Available Finance and Operations Entities table (mserp_virtualentityconfigurations), look for the entity properties in the AOT: IsPublic must be set to Yes, and both PublicCollectionName and PublicEntityName must be populated. Private entities (IsPublic = No) cannot be exposed as Virtual Entities.

[!WARNING] Exam Trap 5: Catch-Up Queue vs. Synchronous Outage Behavior Exam questions will present a scenario where network connectivity between F&O and Dataverse is severed during regular business hours and ask if all financial postings are blocked. Dual-write enters Catch-Up / Paused state and stages outbound transactions in the local queue table (DualWriteCatchUpQueue), allowing local ERP users to continue invoicing without downtime, replaying the queue once connectivity is restored.