7.2 Configuring Access to Model-Driven Apps, Forms, and Views

Model-driven apps use role-based access control end to end. Unlike a canvas app — which you share with named users or Microsoft Entra groups — a model-driven app is shared by associating security roles with the app. Understanding that distinction, and the two gates every user must pass, is the heart of this exam objective.

Sharing the App: Assign Security Roles

To share, go to make.powerapps.com > Apps, select the ellipsis (...) next to the app, and choose Share. In the Share pane you pick one or more security roles (for example, a custom "Event Staff" role, or built-in roles like Basic User) and optionally add individual people or teams. Sharing therefore does two things at once: it records which roles are allowed to open the app, and it can assign those roles to the listed users.

A user can open the app only when both of these are true:

1. The user has been assigned a security role (directly or through team membership) that is associated with the app.
2. That role grants the privileges the app needs — at minimum Read on the tables shown, plus Model-driven App read privileges and environment access.

The classic exam trap: an admin emails a colleague the app URL. The colleague signs in and either can't find the app, sees an empty navigation, or hits a permission error. The cause is almost never the link — it is that the colleague was never given a role associated with the app, or their role lacks table privileges. The fix is in the Share pane and role assignment, not in re-sending the URL.

App-Level vs. Data-Level Security

Think of access as two independent gates:

• App-level security — is this role allowed to open this app at all? Controlled entirely by the Share pane association.
• Data-level security — once inside, what rows and operations can the user touch? Controlled by the privileges in their security roles: Create, Read, Write, Delete, Append, Append To, Assign, and Share, each scoped to a level (None, User, Business Unit, Parent: Child Business Units, or Organization).

A user might pass the app gate but see "You don't have permission" on a record because their role lacks Write on that table. Conversely, a user with Organization-level Read on every table still cannot open the app if no role of theirs is associated with it. Environment access is a third, outer gate: users must be enabled in the environment (often via a Microsoft Entra security group bound to the environment) before either app or data security matters.

Form-Level Security by Role

Main forms support security by role. In the form designer (or the table's Forms list), open the form's settings and choose Enable security roles, then select the roles allowed to use that form. Behavior at runtime:

• A user with an allowed role sees the form normally.
• A user without any allowed role skips that form and falls through the form order to the next form they can use.
• Every table should keep a fallback form (a form with no role restriction) so users never land on "no available form."

Typical scenario: an "HR Case - Manager" form with salary fields is restricted to the HR Manager role, while everyone else uses the standard "HR Case" form.

Views: Not Securable

There is no per-role security on views. System views are visible to every user who has Read privilege on the table and whose app exposes that view. Personal views can be shared with specific users or teams, but that is convenience sharing, not enforcement. This drives an important exam rule: never rely on hiding a view to protect data. If rows are sensitive, restrict them with security role privilege levels, business units, row sharing, or column-level security — the view is only a filter over what the user may already read. Similarly, removing a form or view from an app (Section 7.1) is curation, not security.

Hiding Navigation by Role

Navigation visibility follows the data: if a user's roles grant no Read privilege on a table, the app automatically hides that table's page from the left navigation for that user. Newer app designer capabilities also let makers control page visibility based on security role/privileges at the subarea level, so a managers-only page can be suppressed rather than shown as a dead link. Remember the hierarchy nuance: visibility rules apply to subareas (pages) — you don't secure areas or groups directly.

Auditing Sign-In and Access (Awareness Level)

For the exam, know where the audit trails live rather than deep configuration:

• Dataverse auditing is enabled per environment in the Power Platform admin center (and per table/column in the table settings) and logs record creates, updates, deletes, and user access events.
• Microsoft Entra ID sign-in logs capture authentication to Power Apps itself — who signed in, when, from where.
• Microsoft Purview unified audit logs surface Power Platform activity for compliance teams.

If a question asks how to prove who opened an app or changed a record, the answer is environment auditing plus Entra sign-in logs — not anything configured inside the app designer.