Dataverse virtual tables expose data from external systems as native Dataverse tables. Power Apps and Power Automate interact with the data through the standard Dataverse interface, without knowing the data lives outside Dataverse.
When virtual tables are the right pattern
- Single source of truth: data must stay in its source system for compliance or governance reasons
- Read-heavy scenarios: virtual tables work best for reading and displaying data
- Integration without duplication: two systems need a shared view without one owning a copy
- Dataverse-native UX: you want model-driven app capabilities against external data
How they work
Virtual tables are defined in Dataverse with columns mapping to fields in the external source. A data provider handles the translation between Dataverse queries and the external system. Microsoft provides out-of-box connectors for SQL Server, SharePoint, Azure SQL, and others.
The performance consideration
Virtual table queries are translated to the external system at query time — every lookup, filter, and related record load is a live query. For high-latency external systems this can make apps feel slow. Test performance with realistic data volumes before committing.
A practical example
Customer data in SQL Server must stay there for contractual reasons. A model-driven app needs to show customer information alongside Dataverse-native service records. Virtual tables expose the SQL Server customer data as a Dataverse table. The data never leaves SQL Server.
If you are duplicating data into Dataverse primarily to make it accessible in Power Platform, investigate virtual tables before building a synchronisation architecture.
Virtual tables are a tool for specific scenarios where data must stay in place but needs to be accessible through Dataverse-native interfaces.
