Microsoft’s Power Platform is constantly growing and evolving. As much as everyone (especially Microsoft) wishes that all parts of the Power Platform worked seamlessly together, the reality is that many parts of the Power Platform existed long before Microsoft started using the word Power to group these technologies together. However, I believe that advancements in virtual tables, specifically for Power Pages, emphasizes the fact that Dataverse should be at the core of any Power Platform implementation.

Power Apps: A Name That Means Different Things To Different People

Before Power Pages got its new name, it was called Power Apps Portals. It was one of the three types of Power Apps, along with model-driven and canvas. I always felt that having Power Apps in the name, while appropriate, did often lead to confusion. This is because the “original” type of Power App, or PowerApp as it was then styled, was canvas apps. Then, model-driven apps were added under the Power Apps umbrella, and finally Power Apps Portals was added. However, while all these technologies served a similar purpose (allowing users to built apps without a lot of code), and so from a marketing perspective they were similar, the underlying technology was very different.

I found that people familiar with the original Power Apps, canvas apps, often assumed that features that they knew and loved about that product would also be apart of the model-driven apps and Power Apps Portals. After all, they are all “Power Apps”!

Unfortunately, that isn’t the case. The best example is connectors. Canvas apps are always built on connectors, which allows you to connect to hundreds of different data sources. One of those connectors happens to be for Dataverse, but that is only one of many options. It is completely possible to have a canvas app without Dataverse.

Model-driven apps and Power Pages, on the other hand, are built on top of Dataverse. You cannot have either without Dataverse. Historically there has been no direct connection between model-driven apps or Power Pages to the connectors – you have to use other parts of the Power Platform, like Power Automate or Power BI, to get access to connectors.

Is this a bad thing? Well, I think in an ideal world, it would be great if you could hook up a connector directly to Power Pages, just like you can with canvas apps. Unfortunately that would require a complete rearchitecture of the product. If this is what you are waiting for, I wouldn’t hold your breath. However, I think recent Power Pages announcements give us insight as to how Microsoft is going to fill in this gap: virtual tables with virtual connector.

Virtual Tables and Virtual Connectors

Virtual tables are a feature of Dataverse where you define the schema of a table, including its columns, yet the actual data resides elsewhere. You can add this table to a model-driven app, or access it via the Dataverse APIs just like you would any other table, but instead of the data being in Dataverse, when that data is required, Dataverse makes the necessary API calls to the external systems to get or update the data. It supports creating, reading, updating and deleting data.

Virtual tables have been around a few years now, but historically in order to use them, you would have had to write code to perform all the necessary API calls to the external system, or use the OData v4 provider that Microsoft included out of the box. However, a new option has become available: virtual connector provider.

The virtual connector provider allows you to use connectors as the data source for your virtual tables. Currently there is preview functionality that supports virtual tables on Power Pages that use either the SQL Server or SharePoint Online connectors. I expect over time that the list of connectors will grow.

Dataverse at its Core

As you can see, this new architecture isn’t about adding new functionality directly to Power Pages. Instead, it’s about supporting functionality that exists in Dataverse. Power Pages doesn’t have connectors, Dataverse now has connectors, and since Power Pages uses Dataverse, Power Pages can leverage that investment.

I think many organizations are seeing the benefit of choosing Dataverse as their primary data store. The ability to customize it with custom tables, columns, and business logic, its built-in security model, out-of-the-box APIs, and its place as a preferred connector for Power BI, Power Automate and canvas apps make it a logical choice for any organization wanting to leverage the Power Platform. Having everything in one place just makes things easier.

However, it doesn’t always make sense to store data in Dataverse (per GB it’s one of the most expensive places to store data). For that reason, I think in not too long, the use of virtual tables is going to start growing exponentially. It gives you much of the benefits of being in Dataverse, without having to pay for all the storage.

Of course, there are downsides to virtual tables. From a performance perspective, it’s rarely better to add an additional layer between your end users and the data they want to access. This is especially true for Power Pages, where users have certain expectations about how quickly a website should load. So I’m still a big believer in keeping as much of your data in Dataverse as you can afford. But, the reality is that most organizations won’t be able to consolidate everything into one place. If an organization wants to use Power Pages but the data needs to come from another system, given the choice between synchronizing data with Dataverse, or pulling it real-time using a virtual table, I’ll choose the latter almost every time.