A solution architect scoping a Dynamics 365 Sales rollout for a distribution client recently asked a straightforward question: does the sales team need to see live Business Central order and inventory data inside their CRM records, or is a nightly sync job good enough? The honest answer took longer than it should have, because Business Central virtual tables, the feature Microsoft built specifically to answer this question, solve it only for a narrower set of scenarios than the AppSource listing and most walkthroughs suggest. The core mechanism works exactly as advertised. Where it falls short is rarely covered in the getting-started guides, and that gap is exactly where a scoping conversation needs to happen before anyone commits to an architecture.
Virtual tables have been positioned, correctly in most cases, as the end of a certain kind of integration project: the one where someone builds a scheduled job to copy Business Central records into Dataverse so Power Apps and Dynamics 365 Sales can read them. That job needs error handling, a schema that drifts every time BC gets a service update, and someone on call when the sync silently stops. Virtual tables remove that job entirely for read-heavy scenarios, just not for every scenario, and the difference is worth planning around before it’s discovered mid-build.
How Business Central Virtual Tables Actually Work
The Business Central Virtual Table plugin, published on AppSource, gives Dataverse a way to read and write Business Central records without copying that data into Dataverse storage. Under the hood, it consumes the Business Central API (v2.0), turns each endpoint’s response properties into virtual table columns, and maps the API’s own relationships into table relations that Power Apps and Power Automate can traverse like any native table. None of that translation happens on a schedule. Every query against a Business Central virtual table becomes a live OData call back to the Business Central tenant the moment a user opens a form, loads a subgrid, or a flow condition evaluates.
That real-time behavior is the actual selling point, and it’s a legitimate one. A Dynamics 365 Sales rep looking at an account record sees the customer’s current balance and open orders as they exist in Business Central right now, not as of last night’s sync window. There’s no data duplication to reconcile, no field mapping table to maintain as BC’s schema evolves, and no separate storage cost in Dataverse for records that already live somewhere else.
What Setup Actually Involves
Getting virtual tables running is a Power Platform admin task more than a developer task, which is worth knowing before anyone estimates the work. The solution installs from AppSource into a target Power Platform environment. Inside Business Central, an administrator enables the corresponding Microsoft Entra application, listed on BC’s own Entra applications page as the option for virtual tables. In Dataverse, the Business Central Virtual Data Source Configuration table needs the target BC environment name and a default company, since every request has to resolve to a specific company context.
Microsoft ships this as a set of managed solutions rather than one package: a company reference table every request depends on, the core plugin support, a catalog of tables available from the connected BC environment, and the generated virtual table definitions themselves. Because that catalog reflects the full breadth of Business Central’s OData surface, tables aren’t visible in Power Apps by default. An admin has to open the Business Central Configuration app and mark each table an app will use, a sensible governance control once you know it’s coming, and a confusing missing-table problem the first time you don’t.
The Tenant Requirement That Ends Some Projects Before They Start
The detail worth checking on the first scoping call, not discovering three weeks into a build, is that the Business Central environment and the Dataverse environment must sit in the same Microsoft Entra tenant. For an organization that has run its Dynamics footprint under one tenant from the start, this is a non-issue. It becomes a real blocker for companies that grew through acquisition and still operate a separate Business Central tenant for a subsidiary, and it comes up constantly on engagements where a client’s CRM and ERP environments were provisioned years apart, sometimes by different vendors, under different tenants.
When that’s the situation, virtual tables aren’t an option regardless of how well everything else fits, and the project falls back to a conventional integration built on Power Automate flows against the Business Central API, or a dedicated integration platform between the two systems. Confirming tenant alignment costs a few minutes of checking admin center settings. Discovering the mismatch after a Power Apps screen is already designed around virtual tables costs a redesign.
Where the Filtering Restrictions Actually Bite
Because every virtual table query is a live OData call, the filtering grammar available to a Dataverse view or an advanced find is exactly as expressive as OData’s filter syntax, and no more. Predicates like does not equal, does not contain, does not begin with, and does not end with aren’t available. A view can’t combine AND and OR groups across different columns the way a native Dataverse table allows, and filtering on related tables or calculated fields isn’t supported either, nor are charts, attachments, images, or any BLOB-backed multiline text field built on a virtual table.
None of that shows up in a basic demo, which is the actual problem. A subgrid or gallery built against a virtual table for a first pass usually works, because the first pass rarely tests anything more demanding than “show me the open orders.” The gap surfaces once a real user asks for something like “show open sales orders where the requested ship date isn’t blank and the customer isn’t on credit hold,” a query needing a does-not-equal check on one column joined with an AND against a second. A native Dataverse table handles that without anyone thinking twice. A virtual table view can’t express it, and the fix ends up being either a purpose-built custom API on the Business Central side shaped for that exact query, or pushing the filtering logic into a Power Automate flow or a canvas app formula instead of the view. Either workaround is manageable, but only if someone anticipated it, and the tutorials rarely mention it exists.
Synthetic Relationships Connect the Models, But Only One Way
Virtual tables can also link to native Dataverse tables through what Microsoft calls synthetic relationships, letting a record like a Dataverse Account display related Business Central sales orders in a subgrid without custom plugin code. Building one means creating a foreign key on the native table first, then defining the relationship in the Business Central Configuration app’s Table Relations screen, mapping the native table’s key columns to the matching virtual table columns.
The relationship, once created, isn’t editable. Changing which columns participate means deleting it and rebuilding from scratch, and refreshing the underlying virtual table’s metadata while a relationship depends on it tends to throw errors rather than update quietly. The practical implication is to stabilize the Business Central side of the schema first: it’s far cheaper to adjust a Dataverse foreign key than to reconstruct several relationship mappings after a field gets renamed on the BC side. It’s also worth knowing upfront that relationships between two virtual tables aren’t supported at all, only between a native table and a virtual table, so an architecture chaining two Business Central entities purely through Dataverse relationships needs a custom API instead.
When Virtual Tables Are the Right Call
Virtual tables fit read-heavy scenarios well: a Power App or Dynamics 365 Sales form that needs current item availability, order status, or account balance without anyone owning a sync pipeline, where the filtering the business needs stays inside basic equality and straightforward AND logic. They’re a poor fit for anything involving attachments or images tied to BC records, analytics that need to chart or aggregate BC data directly, filter logic needing negation or mixed AND/OR groups, and any architecture spanning two Entra tenants.
The habit worth building into every Business Central to Dataverse integration scope is prototyping the specific filter and subgrid scenarios the business will actually use, not a generic list view, before the architecture is locked in. Almost every gap covered here only shows up once a real filter requirement meets OData’s grammar, and that’s cheap to test in the first week and expensive to discover after Power Apps screens are already built around the wrong assumption. Teams we’ve helped scope this kind of integration get the most value out of virtual tables when the tenant check and a short filter-requirements workshop are treated as the first two deliverables, not something left until a screen doesn’t do what the demo implied it would.
Virtual tables genuinely remove a maintenance burden that used to be permanent: the sync job nobody wanted to own, the schema drift nobody wanted to chase down. What they don’t remove is the need to know, before the architecture is set, exactly which filters, which tenant, and which record types the integration actually has to support.
#BusinessCentral #DataverseIntegration #VirtualTables #PowerPlatform #ERPIntegration #DynamicsConsulting
No comment yet, add your voice below!