Virtual Tables and OData 4.0 in Dataverse

Introduction to Virtual Tables

Virtual Tables are one of the most advanced features of Microsoft Dataverse, enabling external data to appear as part of the native database. Unlike standard or activity tables, data is not physically replicated within Dataverse but remains in the original source database. This architecture allows seamless integration of external systems while maintaining data consistency and reducing storage costs.

Technically, a Virtual Table consists of two primary components:

• The metadata stored in Dataverse, defining structure and relationships.
• The data provider plug-in that manages the connection to the external data source.

This model allows end users to access and interact with external data through model-driven apps, dashboards, and automations, just as if the data were local.

Available Providers and OData 4.0 Integration

Creating a Virtual Table requires a provider compatible with the external database’s API. Microsoft provides an integrated OData 4.0 provider that connects to any source exposing a compliant endpoint. This includes SQL databases, web applications, and ERP systems supporting OData.

Additionally, a provider for Azure Cosmos DB is available for free from Microsoft AppSource. Developers may also create custom providers to support proprietary APIs or legacy systems not compatible with OData.

Microsoft has also introduced Virtual Connectors, allowing Power Platform connectors to serve as data sources for Virtual Tables. Supported connectors include SQL Server, SharePoint, and Microsoft Excel Online (Business).

Limitations and Design Considerations

Virtual Tables are not a one-size-fits-all solution for every integration scenario. Understanding their limitations is essential for sound architectural design:

• No support for auditing, column security, offline mode, or change tracking.
• They can only be organization-owned, not user/team-owned.
• They do not support certain Dataverse column types (e.g., Currency, Image, Customer).
• They are not compatible with some automation features or Business Process Flows.

Despite these constraints, Virtual Tables deliver strong performance for read-only or visualization scenarios with large data volumes, where physical migration would be inefficient.

When to Use Virtual Tables

According to Microsoft Power Platform Enterprise Architecture best practices, Virtual Tables are recommended when:

1. External data does not need to be modified directly in Dataverse.
2. The data volume is too large for physical migration.
3. Consolidated data visualization from ERP, CRM, or data warehouses is required.
4. Corporate compliance disallows physical replication of data in the cloud.

During migration scoping, each table should be assessed: if it is not editable or involved in business processes, it can be represented as a Virtual Table instead of being migrated physically.

Step-by-Step: Creating a Virtual Table

The process of creating a Virtual Table in the Power Apps Maker Portal involves the following key steps:

• Install or enable a compatible data provider (OData 4.0, Cosmos DB, or custom).
• Configure the connection to the external data source.
• Define the virtual table structure in Dataverse (fields and keys).
• Associate the table with a model-driven app for visualization.

Microsoft’s official documentation describes this in detail: Create and edit virtual entities.

Figure: Virtual Table integration flow with OData 4.0 provider