Power Apps Portal / Power Pages – Permission Model

As we have seen in our previous blog post(s), Power Pages is built on top of Power Apps portals. So, the Power Pages site also follows the same permission model. In this blog post let us refresh our memory on the Power Apps portal permission model at a very high level

Power Apps portal/Power Pages site can be accessed by two types of users. Authenticated users and Anonymous users. Portal can be accessed by either one set of users or a combination of the below two sets.

1. Authenticated Users – Users will be logging into the site to see the website content
2. Anonymous Users – Users do not need to be logging into the site to see the website content

Points to remember

Below points should be kept in mind before we understand the Power Apps Portal or Power Pages permission model

• Dynamics 365 users or Dataverse users are not by default your uses in the Power Apps portal or Power Pages site
• Dynamics 365 users or Dataverse users should register on the Portal login page to become portal user.
• Power Pages/Power Apps portal will create a “Contact” record in the Dataverse table while the user register on the site login page
• Portal is running on a separate security model. i.e., Dynamics 365 roles will not apply to the Portal
• If the contact record already exists in Dataverse, they can be invited to the portal using out-of-the-box

Permission Model at a simple glance

Web Roles

Web Roles is a container of a user’s permissions. Meaning this itself will not give any permissions instead it is just a placeholder of either the page level permissions or table level permissions. Dataverse Contact Record will get assigned to a single Web Role. Web Role will have Page-level permission (If permission is set at page level) or Table-level permission (if permission is set at table level) or a combination of both.

This web role will then be assigned to a portal contact/user and the user will receive the defined permissions

Pages Permission

Pages are nothing but a place where you will display the data. Permissions can be set as page level. If a page has permission set, then user should have access to access the page. If page does not set any permission, then it can be accessed by even an anonymous user.

In a simple way we can say that a user who does not have access to a certain page will neither be able to see the page in the navigation menu nor will the user be able to navigate directly to its URL without it erroring out

Set Anonymous access to a page

A page with Page available to everyone set to On is available anonymously. This option is available on the root page of a website, or a child page that has the parent page with this option set to On.

Set restricted access to a page

When Page available to everyone is set to Off, the page isn’t available to anyone by default. You can select specific roles that you want to allow access to this page.

Use Select roles to choose which roles will be allowed to access the page. Only users from the roles you select here will have access

Child page permissions

A child page can inherit permissions from the parent page, or it can be configured with unique permissions.

Table permissions

If a page have data (Dataverse data) then Table permission need to set properly to make sure users are seeing the correct data

In the next episode let us see how the Dataverse table (LIST) can be used to work with Dataverse table data.

Happy learning !!!

Dynamics 365 Portal

Check the same blog on my dynamics 365 community site: https://community.dynamics.com/365/b/raja-subramanian—blogs