When working with Power Pages (formerly Power Apps Portals), understanding Web Roles and Table Permissions (formerly called Entity Permissions) is crucial for controlling who can access what. These two components work together to define user access, but they serve different purposes and operate at different levels of the portal’s security model.
This guide provides a clear, detailed, side-by-side comparison of Web Roles and Table Permissions, explaining their purpose, differences, how they interact, and best practices—perfect for mastering portal security.
What Are Web Roles?
A Web Role in Power Pages defines who the user is in terms of their identity and classification. It categorizes portal users into groups like Admin, Registered User, Member, Anonymous User, etc.
✔️ Purpose:
To group users and assign security context for access to web pages, table data, forms, lists, and other portal elements.
Example:
- A user with the “Student” Web Role can access course materials.
- A user with “Support Agent” Web Role can view and update support tickets.
What Are Table Permissions?
Table Permissions define what data actions a user can perform on Dataverse tables (formerly Common Data Service). These actions include: Read, Create, Update, Delete, Append, and Append To.
Purpose:
To secure Dataverse data and define what actions a user can perform on records.
Example:
- A user with read permission on the “Job Applications” table can view application records.
- A user with create/update/delete on the “Support Cases” table can manage customer issues.
Relationship Between Web Roles and Table Permissions
Web Roles grant identity. Table Permissions grant actions.
They work together:
- You assign Table Permissions to a Web Role, not directly to a user.
- A user gains permission to a table only when their Web Role includes that permission.
Flow:
- User logs in → Identified as a Contact.
- Contact is assigned a Web Role.
- Web Role includes specific Table Permissions.
- User can now interact with data based on those permissions.
Comparison Table: Web Role vs Table Permission
| Feature | Web Role | Table Permission |
|---|---|---|
| Primary Function | Define user identity/role | Define data access actions |
| Scope | Portal-wide | Specific to Dataverse tables |
| Assigned To | Contacts (users) | Web Roles |
| Used For | Controlling access to: – Web Pages – Web Files – Entity Forms – Lists | Controlling access to: – Table records – Form/List data behavior |
| Permissions Included | None directly | Read, Create, Update, Delete, Append, Append To |
| Configuration Location | Portal Management App > Web Roles | Portal Management App > Table Permissions |
| Usage Example | “Managers” can view HR dashboard | “Managers” can view all records in the “Leave Requests” table |
| Security Layer | Identity-based grouping | Data-level access |
| Anonymous Users | Yes, Web Role can be set to allow unauthenticated access | Limited (Table permissions usually target authenticated users) |
📘 Example Scenario
Scenario:
You have a “Student Portal” where:
- Only logged-in students can view their enrolled courses.
- Admins can see all courses.
- Guests (anonymous) can only view a welcome page.
Setup:
| Component | Configuration |
|---|---|
| Web Roles | Create: Student, Admin, Anonymous |
| Table Permissions | – Courses Table: Student role = Read (Contact scope) Admin role = Read (Global scope) |
| Page Permissions | – Enrolled Courses page: Accessible to Student and Admin roles – Welcome page: Open to Anonymous role |
Security Best Practices
- Never rely solely on Web Roles to secure data. Always use Table Permissions for Dataverse tables.
- Use multiple Web Roles when needed – one for authentication, one for data access.
- Use scoped permissions (Contact, Parent, Account) to limit data exposure:
- Contact scope = Users can only access their own records.
- Global = Users can access all records of that table.
- Keep Web Role names intuitive, like
HRManager,RegisteredUser,Guest. - Test each role using test users in your staging portal.
When to Use What?
| Use Case | Use Web Role? | Use Table Permission? |
|---|---|---|
| Controlling who can see a web page | Yes | Not required |
| Showing/hiding buttons based on role | Yes | Not required |
| Controlling who can view records in a table | Yes (indirectly) | Required |
| Securing form submissions | Yes (for visibility) | Yes (for create permission) |
| Displaying different homepage layout for admins | Yes | Not required |
| Allowing only account managers to see related contacts | Yes | Yes (with Parent scope) |
Final Thoughts
- Web Roles are the identity layer in Power Pages.
- Table Permissions are the data layer security mechanism.
- For secure and scalable portals, you must use both in tandem.
- Think of Web Roles as “who the user is” and Table Permissions as “what they can do with data.”
By combining the two smartly, you can build complex, multi-layered portal security that’s both user-friendly and data-protected.