Power Pages (formerly Power Apps Portals) allow you to build secure, role-based web applications that can serve internal and external users. One of the most crucial elements in building a secure Power Pages site is Web Roles, which control what users can view, edit, or access across the portal.
In this guide, we’ll explore Web Roles deeply — what they are, how to configure them, and how they can be used for securing content and functionality in your portal.
1. What Are Web Roles in Power Pages?
Web Roles are user access levels assigned within Power Pages. They allow you to:
- Control page visibility and content access
- Manage permissions to Dataverse data via Entity Permissions
- Apply role-based logic using Liquid, CSS, and JavaScript
- Enable or restrict access to authenticated features
There are two types of users in Power Pages:
- Anonymous Users (not signed in)
- Authenticated Users (signed in through Azure AD B2C, Microsoft Entra ID, or local authentication)
You can assign web roles to authenticated users to define what they can or cannot access.
2. Where Are Web Roles Managed?
Web Roles are configured using the Portals Management App. This app allows you to manage:
- Web Roles
- Web Page Access Control Rules
- Table Permissions (Entity Permissions)
- Content Access
To access:
- Go to https://make.powerapps.com
- Open Apps > Portals Management
- Navigate to Web Roles
3. Creating a Web Role – Step-by-Step
Step 1: Open the Portals Management App
- Launch the app as mentioned above.
- From the left pane, select Web Roles.
- Click + New to create a new role.
Step 2: Fill Out Web Role Details
Field | Description |
---|---|
Name | A descriptive name like “Registered Users” or “Admin” |
Website | Select the appropriate Power Pages site |
Authenticated Users Role | Check this box if it should apply only to signed-in users |
Anonymous Users Role | Check this if it applies to users who haven’t signed in |
Description | Optional, but useful for documentation |
Once done, Save and Close.
4. Assigning Web Roles to Users
Web Roles are not assigned manually via a user profile, but rather through Contact records in Dataverse.
How to Assign:
- Go to the Contacts table in Power Apps or Portals Management.
- Open a contact record (the user).
- Under Web Roles, add the desired role(s).
- Save the record.
This applies the permissions and access controls defined in that Web Role to the user.
5. Use Cases for Web Roles
Use Case | Web Role Configuration |
---|---|
Members-only content | Create a “Members” role and secure specific pages |
Admin dashboard | Create an “Admin” role with page access + full table permissions |
Anonymous view only | Use Anonymous Users Role to limit access to public pages only |
Role-based navigation | Use Liquid to display menus or links conditionally |
6. Web Page Access Control with Web Roles
You can secure specific pages by associating them with Web Roles.
How:
- Go to Web Pages in the Portals Management App.
- Open a page to secure.
- Scroll to Access Control Rules.
- Add a new rule:
- Type: Read (to allow viewing)
- Web Role: Select the role allowed to view the page
- Scope: Either the page itself or descendants too
Only users with that role can access the page.
7. Table (Entity) Permissions Using Web Roles
Web Roles are also tied to Table Permissions (previously known as Entity Permissions), which allow users to interact with Dataverse tables securely.
Example:
To allow “Registered Users” to submit a contact form:
- Create a Web Role called “Registered Users”
- Create a Table Permission with:
- Table Name:
Contact
- Scope: Self
- Permissions: Create, Read, Update
- Assign the Web Role
- Table Name:
- Publish the permission
Now, users with that role can submit and manage their contact data.
8. Role-Based Logic in Liquid Templates
Liquid templates allow you to conditionally show/hide content based on Web Roles:
Example 1 – Show content only to Admins:
{% if user.roles contains 'Admin' %}
<a href="/admin-dashboard">Admin Dashboard</a>
{% endif %}
Example 2 – Hide download link from non-members:
{% unless user.roles contains 'Members' %}
<p>This content is for members only.</p>
{% endunless %}
9. Managing Anonymous and Authenticated Users
User Type | Web Role Usage |
---|---|
Anonymous | Assign roles for public viewing, restrict submission forms |
Authenticated | Assign roles post-login to unlock protected content or features |
You can configure roles that apply automatically upon login, especially useful for public users who register.
10. Using Multiple Web Roles
A user can have multiple Web Roles assigned. For example:
- A user can be both Editor and Contributor
- You can layer permissions by assigning multiple roles to one contact
Make sure the permissions across these roles don’t conflict.
11. Testing Web Roles
To test:
- Sign in using a test account.
- Ensure it’s linked to a contact with the correct web roles.
- Try accessing secured pages or features.
- Use incognito mode to test anonymous access.
Tip: Build different test users for each major role and switch between them during testing.
12. Best Practices
Best Practice | Description |
---|---|
Use meaningful names | “Admin”, “Author”, “Support Agent” instead of “Role1” |
Keep it minimal | Don’t overload users with too many roles |
Secure sensitive pages | Always test that restricted pages are not accessible without roles |
Use role-based redirects | Send users to appropriate dashboards upon login |
Combine with Table Permissions | For full data security, always pair Web Roles with Table (Entity) Permissions |
13. Common Issues and Fixes
Issue | Cause | Fix |
---|---|---|
Page shows “Access Denied” | Web Role not assigned or missing access rule | Verify user’s Contact record and Access Control Rules |
Data not saving | Table Permission missing | Create appropriate Table Permission and link Web Role |
Navigation links showing to everyone | Role check missing in Liquid | Use user.roles contains logic in Liquid |
Authenticated user can’t log in | Contact record not created or synced | Verify contact creation and authentication provider configuration |