There is no Power Pages without Dataverse

Now that Power Pages has reached General Availability, interest in Pages is dramatically increasing, and makers want to start building! Before you do though, please take a step back-- We need to talk Dataverse. I've been the portals person-- or rather, now the Pages person-- at Microsoft for a few years now. I've worked with some of our largest portals/Pages deployments in both the commercial and public sectors and still train our customers on a weekly basis. With the influx of new would-be Pages makers, I want you all to be setup for success and minimize frustration!

Understand the context

The ADXstudio Portal was an ISV solution released back in the days of Microsoft Dynamics CRM, consisting of a CRM solution with configuration entities and a VS .NET web application project. This was acquired ~2016 and was rebranded to variations of Dynamics/CRM/365 Portal as it was still built on top of Dynamics CRM/365. This eventually became Power Apps portal when the Portal Studio was released (a nifty WSIWYG designer), but was still not a true "Power App." Portals were still built on Dataverse (the data source for Dynamics) and had the same configuration tables in the Portal Management model-driven app that originated in ADX's CRM solution.

A short time later, Power Apps portals evolved into Power Pages, which is where we are at today. Power Pages has an updated studio (Power Pages Studio), but it is still built on Dataverse. All configurations made from the studio get stored in Dataverse and can be viewed from within the very same Portal Management model-driven app.

Learn Dataverse

While Power Pages is an official standalone member of the Power Platform, it cannot be decoupled from Dataverse.

Dataverse is the only out of the box data source that Power Pages connects to. It is what the application is built on top of, and using other Power Platform connectors is not going to work in the same way that it does for Canvas Apps and Power Automate flows. For example, you can use a SharePoint list as a data source for a Canvas App-- this is not the case for Pages. Natively, it is only Dataverse. This makes sense - in portals days, the portal was created to act as a way to extend Dynamics 365 by allowing external audiences to interact with the data.

As I mentioned, all configurations made in the click-to-configure Studio get stored as records/rows in Dataverse, and is maintained through a model-driven app. There is not yet 100% parity between the studio and the model-driven app, so you will be working outside of the studio at some point in your configuration journey.

The tables used to surface components in Pages-- Lists and Forms-- are simply bridge tables that connect to Dataverse forms and views. As such, configuring a List or a Form to display in the Pages website requires an understanding of how to configure a view or form in Dataverse.

When it is time to migrate your Pages website from a development environment to production, you will not only have to move the Pages website configuration using the CLI or migration tool, but you will also need to bundle these Dataverse components that you built into a solution and follow proper Dataverse ALM.

Understand security
Given that you must understand Dataverse and its security model, you must also understand the Pages security model.

Authentication
When planning for your portal deployment, one of the first questions that will inevitably be asked is-- Will your end-users be logging into the portal and be treated as authenticated users, or will they be accessing anonymously as guests? Power Pages supports both scenarios, and you can even use a combination of the two. If you will be requiring or allowing users to register and login to the portal, various external identity providers are available for configuration.

Yes, you can turn off open registration so not just anyone can register. This will ensure that only those that have been invited (see below) to the website will be able to register.

Users are Dataverse contacts, not AAD users. If you are having internal tenant users access the website, it is still their Contact record accessing, not their user. Security is therefore configured to the contact-- specifically, these are tied to the contact record's relationship to the other tables. Business units or Dataverse security roles do not apply here.

When a user registers for the website--or signs in if they are using Azure AD-- a contact record is created in Dataverse. If the contact record already exists in Dataverse, they can be invited to the website using out of the box functionality. The contact record will then store the user's identities and web roles.

Web Roles
Again, Dataverse security roles will not apply to the Power Pages website! Granted, the general concept is not too different here. In the website's case, a user's persona is defined by the Web Role(s) that they have been assigned. Web Roles themselves will not have permissions stored on its record. Rather, think of a web role as a container table for permissions. It is only the web role that is then directly assigned to users-- or rather, contact records. All of this occurs from within Dataverse.

Page Permissions
Power Pages is a website; it has web pages! Naturally, we are able to specify permissions at the web page level. We can use permissions to restrict user access to certain pages to those that are logged in or who may have a specific web role. If applied, a user who does not have access to a certain web page will neither be able to see the web page in the navigation menu nor will the user be able to navigate directly to its URL without it erroring out. In a hierarchical setting, page permissions can also be used to secure entire branches of a website through inheritance.

Table Permissions
If we've opted to implement Power Pages, chances are that we have done so in order to extend our Dataverse data to an external audience. If that's the case, then we need to ensure that we're taking into account our security at the table level. Table permissions are what determine the CRUD actions that users can take on specific records. Yes, that means that we can indeed apply long sought-after record-level security here, which is done via Dataverse relationship definitions. To effectively configure table permissions on your data, you will have to have an understanding of your Dataverse data model.

Realistically, you are going to be using a combination of page and table permissions. We may need to restrict users from specific web pages or branches of the website. If web pages contain Dataverse table data, then we also need to ensure that said table has been secured with table permissions.

I repeat: LEARN DATAVERSE
A Power Pages project is not like a Canvas App project - Power Pages requires architecting a Dataverse data model (build an ERD!!) and designing a website's web page hierarchy. The latter part is assumed, but many makers seem to bypass the step of creating a proper relational data model. Because security is tied to this data model, you are risking an insecure design in the short term. In the long term, you are risking technical debt when you want to expand functionality.

Resources

• Where to start if you are new to Dataverse:

  • Learn about the data model of Dataverse: Get started with Microsoft Dataverse​​​​​​​

  • Learn how to customize Model-driven apps, whose components are used in Power Pages: Intro to Model-driven apps

• General Power Pages upskilling: Get started with Power Pages tutorials | Microsoft Learn

Key takeaway: Please slow down. Learn Dataverse, whiteboard your data model, and THEN build.

Skylar Shonblom

Power Pages: How a Microsoft Cloud Solution Architect can help