---

Microsoft Power Pages, formerly known as Power Apps Portals, enable organizations to build secure, low-code websites that interact with Dataverse and other Microsoft ecosystem services. These portals often serve external users—partners, customers, or contractors—who need limited, role-specific access to data and functionality.

To control what these external users can see or do, custom web roles are essential. Whether you’re building a customer self-service site or a partner collaboration hub, understanding how to define and manage custom roles for portals ensures your data stays secure while providing a smooth user experience.

---

What Are Web Roles in Power Pages?

Web roles are the authorization mechanism used in Power Pages to define what authenticated (or unauthenticated) users can access on the portal.

Web roles determine:

• Page access
• Table permissions
• Content visibility
• Access to entity forms, views, lists, and workflows

There are three types of users in a portal:

• Anonymous: Unauthenticated visitors
• Authenticated: Signed-in users (via local accounts, Azure AD, etc.)
• Administrative: Internal users (typically system administrators)

---

Key Components of Portal Security

To understand how web roles fit in, it’s important to understand how portal security is structured:

Component	Purpose
Web Role	Defines what a user can do (e.g., View Cases, Submit Feedback)
Web Page Access Control Rule	Controls which web pages are accessible
Table Permissions	Defines CRUD rights on Dataverse tables
Entity Forms/Lists	Surface Dataverse data through forms and views
Portal Users (Contacts)	External users, usually linked to a Contact record

Web roles are associated with Contact records, not with standard Azure AD user records (unless you’re using Azure AD B2C).

---

Creating Custom Web Roles: Step-by-Step

Let’s walk through the process of creating and assigning a custom role in Power Pages.

Step 1: Define Your Access Needs

Start by answering:

• What parts of the portal should be accessible to different users?
• What data tables are involved?
• Should users have read, write, or create permissions?

For example, if you’re building a Partner Portal, you might need:

• Partner Viewer: Can see published documentation
• Partner Admin: Can submit and track opportunities

Step 2: Create the Web Role

1. In Power Pages management area or Power Apps Maker portal:
   • Navigate to Web Roles table.
   • Click + New Web Role.
2. Fill in the key fields:
   • Name: E.g., Partner Admin
   • Website: Select your portal website
   • Authenticated Users Role: Yes
   • Anonymous Users Role: No (unless needed)
3. Save the role.

Step 3: Assign Table Permissions

If users need access to Dataverse tables (e.g., Opportunities, Cases), define Table Permissions.

1. Navigate to Table Permissions.
2. Create a new permission record:
   • Table Name: E.g., Opportunity
   • Access Type: Contact or Account-based
   • Permissions: Read, Create, Append, etc.
3. Associate this permission with your custom web role.

🔒 Table permissions are required to display or edit data using forms, views, or lists.

---

Linking Web Roles to Users

Portal users are linked to Contact records. To assign a web role:

1. Open the Contact record for the portal user.
2. Scroll to the Web Roles subgrid.
3. Click + Add Existing Web Role.
4. Select the appropriate custom role(s).

The user will now inherit the access defined by that web role.

---

Controlling Page-Level Access

To restrict portal page access:

1. Go to Web Page Access Control Rules.
2. Create a new rule:
   • Web Page: The page you want to restrict
   • Right: Read, Write, etc.
   • Web Role: Assign your custom role

This ensures only users in the given role can view the page. You can stack multiple roles for different sections of the portal.

---

Example Use Case: Customer Self-Service Portal

Scenario:

You’re building a portal for customers to:

• View and update their profile
• Submit support tickets
• View only their own tickets

Roles:

• Customer: Can view and create their own cases
• Guest: Can only browse FAQs (anonymous)

Setup:

1. Create web roles:
   • Customer (authenticated)
   • Guest (anonymous)
2. Assign table permissions:
   • Cases: Read, Create (Contact Scope)
   • Knowledge Articles: Read (Global Scope)
3. Restrict page access:
   • Submit Ticket and My Cases pages: Customer role only
   • Knowledge Base page: Open to all
4. Configure views/forms:
   • Add Entity List for Cases, filtered by current user
   • Add Entity Form for case submission

---

Advanced Security Techniques

1. Use Liquid Templates for Dynamic Control

You can use Liquid syntax in web templates or content pages to show/hide content based on roles:

{% if user.roles contains 'Partner Admin' %}
    <a href="/submit-opportunity">Submit Opportunity</a>
{% endif %}

2. Custom JavaScript for UI Control

For front-end UX, you can enhance security using JavaScript to hide buttons or features, although this is not a replacement for server-side permission checks.

3. Security via Azure AD B2C

For enterprise portals, integrate Azure AD B2C to:

• Enable external identity providers (Google, Facebook, etc.)
• Apply conditional access and MFA policies
• Assign roles at the identity provider level

4. Audit and Monitor Access

Use Dataverse auditing and Microsoft Entra logs to track portal sign-ins, data access, and changes made by users.

---

Common Pitfalls and How to Avoid Them

Pitfall	Solution
Anonymous users accessing secure data	Ensure web pages and forms are restricted via access control rules and table permissions
Data showing for all users	Set Table Permission Scope to Contact or Account
Roles not applying	Check if web role is assigned to the correct Contact
Pages accessible via URL even if hidden	Use Web Page Access Control, not just navigation settings
Flow or integration failing	Ensure service accounts have required roles and table permissions

---

✅ Best Practices for Managing Portal Roles

• Plan your roles upfront: Avoid ad-hoc creation to maintain clarity.
• Use naming conventions: E.g., Customer_ReadOnly, Partner_Admin
• Avoid over-permissioning: Stick to the principle of least privilege.
• Automate role assignment: Use Power Automate or plugins for large-scale assignments.
• Document your role design: Helps with audits and troubleshooting.

---