What Is a Capability of Virtual Tables in Dataverse?

Answer Correct answer: B — Virtual tables retrieve data from an external data source rather than storing it in Dataverse.

A company is evaluating the capabilities in Dataverse and the scenarios for using virtual tables. You need to identify the capabilities of virtual tables. What is a capability of virtual tables?

  1. Virtual tables store data in the Dataverse environment.
  2. Virtual tables retrieve data from an external data source. Correct Answer
  3. Virtual tables can be configured for user and team ownership.
  4. Virtual tables support Dataverse auditing.

Community Votes

B
100%

100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The question tests whether you know that a virtual table is a pointer, not a container — the trap is confusing virtual tables with standard Dataverse tables that store rows and support ownership and auditing.

Virtual tables (virtual entities) in Microsoft Dataverse expose data that physically lives in an external system, so their defining capability is retrieving data from an external data source rather than storing it inside Dataverse. This page confirms option B as the correct capability and explains why storage, ownership, and auditing claims do not apply.

The most common wrong pick is A, assuming virtual tables store data in Dataverse; in reality the rows remain in the external system and Dataverse only surfaces them at runtime, so nothing is persisted locally.

Community Discussion (3 comments)

user861243 👍 1 Selected: B
Definitely B. Virtual Entity = External data source
JohnChung 👍 2 Selected: B
Virtual tables act like a bridge between external data sources and Dataverse Link: https://learn.microsoft.com/en-us/power-apps/maker/data-platform/create-edit-virtual-entities
DaanEp 👍 3 Selected: B
The other options are not accurate: A. Virtual tables do not store data in the Dataverse environment; they retrieve data from external sources. C. User and team ownership is typically associated with tables storing data directly in Dataverse, not with virtual tables that connect to external sources. D. Dataverse auditing is a feature associated with tracking changes in Dataverse tables, not specifically with virtual tables. So, the correct answer is B. Virtual tables retrieve data from an external data source.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

A virtual table (historically called a virtual entity) is defined in Dataverse with metadata such as columns, forms, and views, but the underlying rows are never written into the Dataverse database. Instead, a data provider — an OData v4 web service, a SQL connection, or a custom plug-in — is called at runtime to read and, where supported, write records in the external system. That is exactly why option B is right: the table's core capability is retrieving data from an external data source. The community answers line up with this reading, with JohnChung describing virtual tables as "a bridge between external data sources and Dataverse", and user861243 summing it up as "Definitely B. Virtual Entity = External data source". Microsoft's own documentation frames it the same way: you use virtual tables when the data must remain in an external system of record.

Why the Other Options Are Wrong

Option A inverts the whole design: data is not stored in the Dataverse environment, it is persisted externally and surfaced through the virtual table. Option C fails because ownership settings such as user/team ownership apply to standard tables that hold their own rows; virtual tables are organization-owned and cannot be reassigned to user or team ownership to change the data location. Option D also fails because Dataverse auditing tracks changes to data actually stored and maintained in Dataverse, and virtual tables do not hold that data. DaanEp's comment makes the same point, noting that virtual tables "do not store data in the Dataverse environment" and that auditing "is a feature associated with tracking changes in Dataverse tables".

Community Comment Notes

Every recorded vote on this item chose B, and the explanations converge on the same distinction between storage and retrieval. JohnChung's bridge metaphor is a useful memory hook, pointing to the create-and-edit-virtual-entities guidance on Microsoft Learn. user861243's short verdict reinforces the equivalence between "virtual entity" and "external data source". DaanEp systematically rules out A, C, and D, which is the exact reasoning the exam expects you to reproduce under time pressure.

Official Reference

Exam Strategy

When a PL-200 item asks about virtual tables, immediately classify the option as either storage-related or retrieval-related; anything describing persisted data, ownership assignment, or Dataverse auditing belongs to standard tables and can be eliminated in seconds.

Frequently Asked Questions

Why can't a virtual table be configured for user or team ownership?

Virtual tables do not hold their own rows in Dataverse, so they remain organization-owned; user and team ownership applies to standard tables that store data locally.

Do virtual tables support Dataverse auditing?

No. Auditing tracks changes to data stored in Dataverse, while virtual table records live in the external system, so Dataverse auditing does not apply to them.

Related Analysis

← Back to PL-200 Study Guide