Dataverse virtual table

What is a Dataverse virtual table?

A Dataverse virtual table is a custom table whose records stay in an external system. Microsoft Dataverse keeps the table's definition and metadata, while a data provider translates reads, and where supported writes, into calls against the source.

Apps, flows, and API clients work with those external records through a normal Dataverse shape, as if they were ordinary rows. No standing copy of the source data is created in Dataverse. This is Dataverse's take on data virtualization: the data is presented where you need it without being moved.

Virtual tables fit when you need current external data inside a Power Platform experience and replication would be unwanted or pointless. They fit less well when you need history, offline access, or heavy analytical queries, which is where a copy earns its keep.

The parts of a virtual table

A virtual table is built from a few pieces that work together. The data source points at where the external data lives. The data provider defines the behaviour for retrieve, retrieve multiple, and any supported write operations.

For connector-based providers, a connection and a connection reference handle access and authentication. Microsoft ships virtual connector providers for a growing set of sources, including SQL Server, SharePoint, Microsoft Fabric, Salesforce, Oracle, and Snowflake, and a built-in OData v4 provider that supports full create, read, update, and delete. When no provider fits, developers can build a custom one, which is a reusable set of Dataverse plug-ins implementing each operation.

The virtual table itself defines the columns and how they map to the source. Every external record needs a stable, unique key that Dataverse can present as its record ID, and that key has to stay put over time.

A worked example: stock from an ERP

A salesperson uses a model-driven app with customers and opportunities stored in Dataverse. The live warehouse stock lives in the company's ERP.

A virtual table shows the available quantity and location per item straight from the ERP. The app does not wait for a nightly stock copy, and the number the seller quotes is the number the warehouse holds right now.

The flip side is dependence. When the ERP is slow or down, the virtual view is slow or down too. The design has to account for errors, timeouts, and ideally a fallback experience, rather than assuming the source is always reachable.

Virtual table versus replication

A virtual table fetches data on use. That gives current values and avoids duplicate storage, but it ties performance and availability to the source. Every screen that shows the table is only as fast and as reliable as the system behind it.

Replication copies data into Dataverse or another target. It supports local queries, historical snapshots, and running independently of the source, at the cost of synchronisation lag and conflict handling. Choose per use case: a product catalogue that can lag by an hour suits replication, while a live availability flag argues for reading the source directly.

Supported operations and keys

Not every provider supports create, update, and delete. What works depends on the source API, the mapping, and the provider, so confirm the operations you need rather than assuming full read-write.

Platform features can behave differently from native tables too. Auditing, some search, offline use, rollups, and certain relationships may be limited or absent, so check current support for each feature a screen relies on. A Dataverse interface does not make the source transactionally identical to Dataverse, and an operation spanning native and virtual records is not automatically one atomic transaction.

Keys deserve care. They must be unique and stable, so avoid using a hash of changeable fields as the identity. If the same source record later gets a different ID, Dataverse sees a new record and existing references break.

Security

Two access models are in play: Dataverse security roles and the external source's own permissions. Decide which identity the provider reads under and how user context is carried through.

Do not hand every external record to every app user through one high-privilege service connection. Filtering and authorisation have to be enforced reliably on the server. Keep sensitive connection values out of logs, use managed secrets, and check which query parameters and error details end up in platform telemetry.

What to watch out for with virtual tables

Push work to the source. Views ask for sorting, filtering, and paging, and a provider should translate those into the source query wherever it can. Local processing of large result sets scales badly.

Measure the source. Watch response time, throttling, and error rates under realistic volumes. A virtual table is not an ETL route or an analytical history layer, so do not press it into that role.

An empty result is not proof of absence. A source error can return a blank list that looks like "no records". Handle failures explicitly so a screen does not quietly present a source outage as valid data. Manage the metadata and connection references through solutions, and test against real volumes and deliberate source failures before a virtual table backs a business-critical screen.