Virtual tables

What it does

A virtual table surfaces data from an external system as if it were a Dataverse table. Rows are fetched from the source at runtime, so nothing is copied into Dataverse. Three pieces make it work: a data provider (plug-ins), a data source row holding the connection metadata, and the table itself.

Key facts

Dataverse ships an OData v4 data provider plus virtual connector providers for sources including SQL Server, SharePoint and Fabric. Developers can build custom providers and install them as a solution.
Existing tables can't be converted to virtual tables. It's a create-new decision.
By default a virtual table has only Name and Id. System-managed columns like Status, Created On and Modified On aren't supported.
Currency, Image and Customer data types aren't supported on virtual table columns.
Virtual tables are organisation owned and don't participate in row-level Dataverse security. Microsoft's guidance is to implement your own security model on the external source.
No auditing, no change tracking, no duplicate detection, no queues, no SLAs, no knowledge management, no mobile offline, no column security, no Dataverse search, no Power Pages solutions.
No dashboards, no charts, no business process flows (activating one throws an unexpected error), no rollup or calculated columns referencing virtual table columns, and a virtual table can't be an activity table.
Column validation metadata isn't enforced. Set a minimum of zero on a whole number column and the source can still return negatives — the property doesn't become a query filter.
Because there's no change tracking, virtual tables can't be synchronised by Azure Synapse Link or the Data Export Service.
The built-in OData v4 provider works over outbound port 443.

When to use / skip

Virtual tables suit reference data that lives somewhere else and must not be duplicated — a product catalogue in ERP, a policy list in a legacy system, anything where a copy would immediately be wrong or would breach a data-residency rule. They're excellent for read-heavy lookup scenarios in a model-driven app. Skip them for anything you need to secure per row, report on, search, take offline, or run process automation against. And be honest about performance: every grid render is a live call to the other system, so the user experience is exactly as good as that system's worst day. If the requirement is really "we want this data in our reports", a copy through a pipeline is usually the right answer and virtual tables are the wrong one.

Configuration decisions

Which provider — a supplied virtual connector, the OData v4 provider, or a custom plug-in — and who owns it for the life of the solution.
Whether the external source can answer filtered, paged queries fast enough for a grid, because Dataverse pushes the work outward.
How you secure the data, given Dataverse row-level security doesn't apply.
Whether users need to write back, and whether the provider supports it.
Where connection secrets live — the Data Source Secret attribute on the data source form exists for exactly this.

Gotchas

Organisation ownership plus no row-level security means everyone with table read sees everything. People assume the Dataverse security model applies and it doesn't.
The external system becomes part of your availability story. When it's slow, your forms are slow, and users blame Dataverse.
Missing Created On and Modified On breaks a surprising number of assumptions in views, filters and downstream tooling.
Business process flow activation failing with an unexpected error is a documented behaviour, not a bug in your build. Save yourself the investigation.
No change tracking means no Synapse Link, so anyone planning analytics over this data needs a different route to it.

Consultant notes

Set expectations about latency in writing, before build. Users compare a virtual table grid to a native one and the comparison never goes your way.
Make the security conversation explicit and early. "Row-level security doesn't apply here" needs to be a signed-off design point, not a footnote.
Test with production-scale data and production network conditions. A virtual table over a dev SQL box with 200 rows tells you nothing.
If the client wants reporting, search and offline over this data, redirect them to replication. Virtual tables will disappoint on all three, and it's better to say so in week one.

Worth revisiting as the virtual connector provider list grows, and if change tracking support ever lands.