A Deep Dive into Virtual Tables in Dataverse for Developers

Virtual Tables in Dataverse allow developers to connect and display data from external systems—like SQL, SharePoint, or REST APIs—directly within Dataverse without storing it locally. They act as a bridge that makes external data appear as native Dataverse tables, enabling users to view and interact with that data in real time through model-driven apps, Power Apps, and Power Automate. This eliminates the need for data duplication or synchronization while maintaining a consistent Dataverse experience. Virtual Tables use a data provider to translate Dataverse queries into the external system’s language, making them ideal for real-time integrations where up-to-date external information needs to be accessed seamlessly within the Power Platform ecosystem.

What Are Virtual Tables?

In Dataverse, a Virtual Table (formerly called Virtual Entity) lets you represent external data inside Dataverse as if it were a native table, without storing the data physically.

Think of it as a “live view” of external data — you can read it (and sometimes write back), but the data stays in the source system.

How Virtual Tables Work?

A Virtual Table acts as a metadata layer between Dataverse and an external data source.

It uses a Virtual Table Data Provider — a plugin-like connector that translates Dataverse queries (OData/FetchXML) into native queries on the external system.

Key Components

How Developers Interact with Virtual Tables

When you query a Virtual Table using Web API, FetchXML, or SDK, Dataverse routes the request to the Data Provider, which:

1. Connects to the external data source.
2. Executes the translated query.
3. Returns results as Dataverse records — dynamically.

No data is stored in Dataverse — it’s retrieved on-demand.

Supported Operations

Architecture Diagram (Conceptual)

Developer Scenarios

1. Building a Custom Data Provider

If no out-of-box provider fits your scenario, you can create one using the Virtual Table Plugin Interface.

Steps:

1. Implement a custom plugin that inherits from IDataProviderPlugin and handles:
• Retrieve
• RetrieveMultiple
• (Optionally) Create, Update, Delete
2. Register your plugin using the Plugin Registration Tool.
3. Create a Data Source entity that uses your provider.
4. Define your Virtual Table and map its columns.

Sample class structure (C#):

public class MyApiVirtualTableProvider : IDataProviderPlugin

{

    public void Retrieve(IPluginExecutionContext context)

    {

        // Translate Dataverse query to API request

        // Deserialize response and return entity collection

    }

    public void RetrieveMultiple(IPluginExecutionContext context)

    {

        // Handle FetchXML or OData queries

    }

}

2. Using the OOB Providers

Microsoft provides several built-in data providers for:

• SQL Server
• SharePoint
• Cosmos DB
• Azure Table Storage
• OData v4
• Microsoft Graph

You can configure these via Power Apps Maker Portal → Tables → New Table → Virtual Table.

Performance Considerations

Virtual Tables fetch data on demand — so latency depends on:

• API performance of the external system
• Network latency
• Query complexity

Tips for optimization:

• Retrieve only necessary columns.
• Apply filters early in your source queries.
• Use caching if external source supports it.
• Use column-level mapping carefully to minimize payload size.

Security Model

Virtual Tables use Dataverse security roles — meaning:

• Access is controlled through Dataverse privileges (Read, Create, etc.).
• However, authentication to the external system is handled by the Data Source configuration (connection credentials or service principal).
• Row-level security depends on the external data source — Dataverse does not enforce it.

Use Cases for Virtual Tables

When to Use vs. When Not to Use

Key Developer Tips

• Always define a unique primary key field in the external data source.
• Test with small datasets first to validate latency.
• For custom providers, handle paging and filter translation properly.
• Use diagnostic tracing to troubleshoot performance.
• If security is critical, integrate Azure API Management as a secure layer.

Hands-on Lab (Developer Practice)

Scenario: Connect Dataverse to an external Azure SQL Database using Virtual Tables.

Steps:

1. Create an Azure SQL table named Inventory.
2. Create a new SQL Data Source in Dataverse.
3. Define a Virtual Table named Inventory Items.
4. Map columns to SQL table fields.
5. Query the table from Power Apps or using Xrm.WebApi.retrieveMultipleRecords.

Expected Output:

You’ll see live SQL data inside Dataverse — updatable if provider supports write-back.

Developer Takeaway

Virtual Tables = “Real-time integration without replication.”

They bridge the gap between Dataverse and external systems while preserving the Dataverse experience for users, forms, views, and model-driven apps.

Summary:

Virtual Tables in Microsoft Dataverse provide a powerful way to access and work with data stored in external systems as if it were native Dataverse data—without physically importing or duplicating it. They enable real-time integration by connecting to external data sources through data providers, allowing users and developers to read and interact with external data seamlessly within model-driven apps, Power Apps, and Power Automate. Virtual Tables support standard Dataverse features such as forms, views, and relationships, ensuring a unified experience. This approach simplifies integration, reduces data redundancy, and ensures users always work with the most current information from connected systems.