8.2 Table Permissions, Web Roles & Page Access Security

Table Permissions, Web Roles & Page Access Security

Security is the foundational pillar of any external-facing web portal. When organizations expose Microsoft Dataverse entities to external users, they must guarantee that users can only view and manipulate the precise records they are authorized to access. Microsoft Power Pages implements a Zero Trust security architecture that completely isolates Dataverse data from the public web until explicit permissions and roles are established.

For the PL-200: Microsoft Power Platform Functional Consultant exam, you must master the configuration of Table Permissions (including all access types and privileges), child table permission hierarchies, Web Roles, and Web Page Access Rules.

---

1. The Power Pages Zero Trust Security Model

Unlike internal model-driven apps where Dataverse security roles govern access based on Business Units and User/Team ownership, Power Pages operates across an external web boundary where visitors are either anonymous or authenticated via external Identity Providers (such as Microsoft Entra ID or Google).

+-----------------------------------------------------------------------------------+
|                    POWER PAGES 3-TIER SECURITY EVALUATION                         |
|                                                                                   |
|  [1. WEB PAGE ACCESS RULES] ───> Can the user view/edit this Web Page / URL?     |
|              │                                                                    |
|              ▼ (If Allowed)                                                       |
|  [2. WEB ROLES] ───────────────> What personas does this Contact possess?         |
|              │                   (Anonymous, Authenticated, Custom Web Roles)     |
|              ▼                                                                    |
|  [3. TABLE PERMISSIONS] ───────> What Dataverse records & CRUD operations are     |
|                                  authorized for these Web Roles?                  |
|                                  (Global, Contact, Account, Parent Scopes)        |
+-----------------------------------------------------------------------------------+

[!CAUTION] Default Data Block: By default in Power Pages, all Dataverse tables have zero access for website visitors. If a consultant places a List or Basic Form on a web page without configuring valid Table Permissions and linking them to a Web Role, the List will render zero rows and the Form will return an "Access Denied" error.

---

2. Table Permission Access Types (Scopes)

A Table Permission defines the scope of records a portal user can interact with in a specific Dataverse table. Power Pages provides four distinct Access Types:

+-----------------------------------------------------------------------------------+
|                         TABLE PERMISSION ACCESS TYPES                             |
|                                                                                   |
|  [1. GLOBAL ACCESS]                                                               |
|     └── Access to ALL records in the table regardless of relationship.            |
|         Best for: Public Product Catalogs, Knowledge Base, FAQ repositories.      |
|                                                                                   |
|  [2. CONTACT ACCESS]                                                              |
|     └── Access scoped via 1:N or N:1 relationship to logged-in user's Contact.    |
|         Best for: User's own Support Tickets, Personal Profile, Orders.          |
|                                                                                   |
|  [3. ACCOUNT ACCESS]                                                              |
|     └── Access scoped via relationship to the user's parent Account record.       |
|         Best for: B2B Portals, Company Invoices, Corporate Asset Management.      |
|                                                                                   |
|  [4. PARENT ACCESS]                                                               |
|     └── Access inherited from a Parent Table Permission via schema relationship.   |
|         Best for: Child rows (e.g., Ticket Comments, Invoice Line Items).         |
+-----------------------------------------------------------------------------------+

Access Types Comparison & Use Cases

---

3. Table Permission Privileges

Within each Table Permission, consultants grant specific granular privileges that dictate allowable CRUD operations:

+-----------------------------------------------------------------------------------+
|                      TABLE PERMISSION PRIVILEGE MATRIX                            |
|                                                                                   |
|   [READ]      ───> Query and display records in Lists and Forms                   |
|   [WRITE]     ───> Update existing record attributes on Edit Forms                |
|   [CREATE]    ───> Insert new records on Insert Forms or Subgrid '+' buttons      |
|   [DELETE]    ───> Remove records via List item actions or Subgrid buttons        |
|   [APPEND]    ───> Associate OTHER records TO this record (Parent side)           |
|   [APPEND TO] ───> Associate THIS record TO another record (Child side)           |
+-----------------------------------------------------------------------------------+

Understanding Append vs. Append To Mechanics

The distinction between Append and Append To is a core concept tested extensively on the PL-200 exam:

• Append: Represents the right to attach or link another record into the current record. You configure Append on the record that is receiving the link.
• Append To: Represents the right to link the current record to another target record. You configure Append To on the record that contains the lookup pointer.

Practical Relationship Example

Suppose a portal user is submitting a new Support Ticket Note (child record) linked to an existing Support Case (parent record):

1. On the Support Case table permission, the user must have Append (allowing other records to be attached to the Case).
2. On the Note / Ticket Comment table permission, the user must have Create and Append To (allowing the new Note to be linked to a Case).

[!IMPORTANT] If the user has Create on Notes but lacks Append To on Notes, or lacks Append on the parent Case, the record creation will fail with a relationship authorization exception.

---

4. Child Table Permissions & Multi-Tier Hierarchies

In complex relational databases, child records should not be exposed globally; their access must reflect the security boundaries of their parent entities. Child Table Permissions use the Parent Access Type to create cascading security trees.

+-----------------------------------------------------------------------------------+
|                      MULTI-TIER PARENT ACCESS HIERARCHY                           |
|                                                                                   |
|  [TIER 1: ACCOUNT (Parent Table Permission)]                                      |
|     └── Access Type: Account Access (Scoped to logged-in user's Company)          |
|            │                                                                      |
|            ▼                                                                      |
|  [TIER 2: PROJECT (Child Table Permission)]                                       |
|     └── Access Type: Parent Access (Inherits via Project -> Account relationship) |
|            │                                                                      |
|            ▼                                                                      |
|  [TIER 3: PROJECT TASK (Grandchild Table Permission)]                             |
|     └── Access Type: Parent Access (Inherits via Task -> Project relationship)    |
|            │                                                                      |
|            ▼                                                                      |
|  [TIER 4: TIME ENTRY (Great-Grandchild Table Permission)]                         |
|     └── Access Type: Parent Access (Inherits via Time Entry -> Task relationship) |
+-----------------------------------------------------------------------------------+

Rules for Child Table Permissions

• A Child Table Permission does not specify an independent access scope (such as Contact or Account); it inherits its scope entirely from its parent.
• Child Table Permissions do not need direct assignment to Web Roles. They automatically apply to any Web Role that is assigned to the root Parent Table Permission.
• Child table permissions can be nested indefinitely across deep relational hierarchies.

---

5. Web Roles Architecture

A Web Role in Power Pages is the equivalent of a security role, grouping Table Permissions and Page Access Rules together and assigning them to portal users (represented as Dataverse contact records).

+-----------------------------------------------------------------------------------+
|                         POWER PAGES WEB ROLE TYPES                                |
|                                                                                   |
|  [1. ANONYMOUS USERS]      [2. AUTHENTICATED USERS]     [3. CUSTOM WEB ROLES]     |
|  - Automatically applied   - Automatically applied      - Assigned explicitly     |
|    to unauthenticated        to ANY logged-in user        to Contacts (N:N link)  |
|    public visitors           regardless of IdP          - Persona-specific        |
|  - Read-only catalogs      - Base portal privileges     - Partner Admin, Manager, |
|  - Marketing pages         - Profile management           Technician, Auditor     |
+-----------------------------------------------------------------------------------+

The Three Types of Web Roles

1. Anonymous Users Role:

   • A special built-in role with the flag Anonymous Users Role = True.
   • Automatically applies to every unauthenticated visitor browsing the site.
   • Used for public-facing data (e.g., Read permissions on a Product Catalog, Knowledge Base Articles, or Store Locations).
   • Only one Web Role per website can be designated as the Anonymous Users role.

2. Authenticated Users Role:

   • A special built-in role with the flag Authenticated Users Role = True.
   • Automatically applies to all authenticated users the moment they sign in with any identity provider.
   • Used for baseline authenticated capabilities (e.g., Read/Write access to the user's own Contact record to manage their profile, Read permissions on general customer announcements).
   • Only one Web Role per website can be designated as the Authenticated Users role.

3. Custom Web Roles:

   • User-defined roles created to implement granular business personas (e.g., "Vendor Manager", "Claims Adjuster", "Billing Administrator").
   • Assigned to specific portal users by creating relationships between the contact record and the adx_webrole record in Dataverse (via the adx_webrole_contact N:N association).

---

6. Web Page Access Rules

While Table Permissions secure Dataverse data records, Web Page Access Rules secure the website sitemap and web page URLs themselves. They control whether a user can navigate to a specific web page or edit its contents on the front-end.

+-----------------------------------------------------------------------------------+
|                        WEB PAGE ACCESS RULE RIGHT TYPES                           |
|                                                                                   |
|  [RESTRICT READ]                                                                  |
|  - Blocks unauthorized users from viewing the target Web Page.                    |
|  - Automatically hides the page from navigation menus and sitemaps.               |
|  - Unauthenticated visitors attempting direct URL access are redirected to Login. |
|  - CASCADES DOWNWARD: Automatically protects all child web pages in hierarchy!    |
|                                                                                   |
|  [GRANT CHANGE]                                                                   |
|  - Grants front-end content management rights to authorized portal users.         |
|  - Allows editing page text, images, and snippets directly in the live browser.   |
|  - Typically assigned to Content Authors, Marketing Admins, or Web Editors.       |
+-----------------------------------------------------------------------------------+

Sitemap Inheritance & Cascading Rules

Web Page Access Rules follow hierarchical sitemap inheritance:

• When a Restrict Read rule is applied to a parent web page (e.g., /Customer-Portal/), all subordinate child pages (e.g., /Customer-Portal/Invoices/, /Customer-Portal/Support/) automatically inherit the restriction.
• If a visitor does not possess a Web Role associated with the Restrict Read rule, the parent page and all child pages are completely hidden from navigation menus and search indexes.