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

Microsoft Certified: Intelligent Applications Builder Associate AB-410

Track your progress as you read

Finished sections get a check mark.

1 Introduction

1.1 About the AB-410 Exam 1.2 How to Use This Study Guide

2 Chapter 2: Designing Power Platform Solutions with AI-Enabled Tools

2.1 Analyzing Requirements and Identifying Components 2.2 Evaluating Built-in Agents for Business Solutions 2.3 Recommending Extensibility Options

3 Chapter 3: Environments and ALM Strategy

3.1 Recommending Environment Types 3.2 Solution and Application Lifecycle Management Strategy

4 Chapter 4: Dataverse Tables and Columns

4.1 Creating and Editing Tables in the Data Workspace 4.2 Configuring Table Properties 4.3 Creating and Modifying Columns

5 Chapter 5: Relationships, AI Data Features, and Data Security

5.1 Configuring Table Relationships 5.2 Configuring Prompt Columns and Row Summaries 5.3 Configuring Public Views and Main Forms 5.4 Configuring Dataverse Security

6 Chapter 6: Model-Driven App Forms and Views

6.1 Creating and Configuring Forms for Model-Driven Apps 6.2 Creating and Configuring Views for Model-Driven Apps 6.3 Creating Generative Pages with Natural Language

7 Chapter 7: Composing, Securing, and Visualizing Model-Driven Apps

7.1 Composing a Model-Driven App 7.2 Configuring Access to Model-Driven Apps, Forms, and Views 7.3 Model-Driven App Charts and Dashboards

8 Chapter 8: Creating and Designing Canvas Apps

8.1 Creating a Canvas App Using Data 8.2 Designing for Accessibility, Performance, Responsiveness, and Usability 8.3 Automating Business Processes from Canvas Apps

9 Chapter 9: Canvas App Components, Variables, and Error Handling

9.1 Reusable Components, Named Formulas, and User-Defined Functions 9.2 Managing Variables and Collections 9.3 Implementing Error Handling in Canvas Apps

10 Chapter 10: Testing Canvas Apps and Creating Agents from Apps

10.1 Testing Canvas Apps with Monitor 10.2 Creating a Copilot Studio Agent from a Canvas App

11 Chapter 11: Cloud Flow Triggers, Connectors, and Approvals

11.1 Recommending Cloud Flow Triggers 11.2 Evaluating and Recommending Connectors 11.3 Managing Approvals with Cloud Flows

12 Chapter 12: Cloud Flow Actions, Control, and Troubleshooting

12.1 Configuring Cloud Flow Actions 12.2 Implementing Flow Control with Conditions and Loops 12.3 Testing and Troubleshooting Cloud Flows

13 Chapter 13: Building Prompts in AI Hub

13.1 Building Prompts from Templates or from Blank 13.2 Adding Inputs to a Prompt 13.3 Adding Knowledge to a Prompt

14 Chapter 14: Prompt Settings, Models, and Consuming AI

14.1 Customizing Prompt Settings and Models 14.2 Consuming Prompts in Apps and Cloud Flows 14.3 Consuming AI Models in Apps and Cloud Flows

15 Chapter 15: Business Rules and Business Process Flows

15.1 Configuring Business Rules 15.2 Configuring Business Process Flows

16 Chapter 16: Calculated Columns and Business Logic Strategy

16.1 Calculated, Rollup, and Formula Columns 16.2 Evaluating Use Cases for Business Logic

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

Key Takeaways Explain This Topic AI

Sharing a model-driven app means assigning one or more security roles to the app — a user needs a role that is both assigned to the app and granted to the user

App access and data access are separate gates: the role must be linked to the app AND carry table privileges (Create, Read, Write, Delete, Append, Append To, Assign, Share) on the data

Form-level security restricts a main form to selected security roles; users without a listed role fall back to another form in the form order or the fallback form

Views cannot be secured per role — any user with Read on the table sees all system views in the app, which is why sensitive data is controlled with row-level security, not view hiding

The classic exam failure: a user opens the shared app link and sees nothing or gets an error because they were never assigned a security role associated with the app

Last updated: July 2026

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:

The user has been assigned a security role (directly or through team membership) that is associated with the app .

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.