Controlling Access to Views in Model-Driven Power Apps Teams Security Roles

In model-driven Power Apps, views are fundamental—users rely on them to browse records, filter data, and navigate through entities. But not all views should necessarily be visible to every user. Microsoft offers a mechanism to manage public system views using security roles, so that only users with appropriate roles see the designated views in their apps. (Microsoft Learn)

In this post, I’ll explain how this feature works, why it matters, and how to enable it in your Dataverse environment.

What Are System Views & Public Views?

• System views are predefined or automatically created views associated with system tables (e.g. Account, Contact) or custom tables. (Microsoft Learn)

• A view created in Power Apps (make.powerapps.com) generally becomes a public view. Public views can be managed via security roles to control which users see them. (Microsoft Learn)

• By default, all system views are available to everyone. That means, unless restricted, every user sees all system views in the view selector. (Microsoft Learn)

However, managing views via security roles introduces filtered visibility: only users who hold the assigned roles will see the managed views in the view selector. (Microsoft Learn)

Important caveat: granting access to a view does not override data-level security. Even if a user can see the view, they will only see records in that view which they also have permission to read. (Microsoft Learn)

Why Use Role-Based View Access?

Here are some use cases and benefits:

• Cleaner UI for users: prevent confusion by hiding irrelevant views from users who don’t need them.

• Security & governance: avoid exposing views that may reveal data structure or sensitive filtering logic.

• Role-based differentiation: show different views for sales staff versus support staff, for instance.

• Compliance: maintain consistency with data access policies and least-privilege principles.

Prerequisites & Setup

Before enabling role-based view access, make sure the following are in place:

1. Enable the feature: the EnableRoleBasedSystemViews organization setting (orgdbsettings) must be set to true (this is done using the OrganizationSettingsEditor tool). (Microsoft Learn)

2. Appropriate permissions: you need to have the System Administrator role in the Dataverse environment. (Microsoft Learn)

3. (Recommended) Auditing enabled: while not required, auditing can help track changes. (Microsoft Learn)

Once that’s done, you can begin managing which public views are visible to which security roles.

How to Manage Public Views with Security Roles

Here's a step-by-step:

1. In the Power Apps maker portal, go to Solutions, and open (or create) the solution containing the table whose views you want to manage. (Microsoft Learn)

2. Within that solution, select the table (for example, Account) and go to its Views area. (Microsoft Learn)

3. Pick a nondefault public view (i.e. one that can be controlled). (Microsoft Learn)

4. Click View settings on the command bar. (Microsoft Learn)

5. Choose the Specific security roles option and select which roles should have access. (Microsoft Learn)

6. Save and publish your changes. (Microsoft Learn)

A few notes:

• If you switch a view from “Everyone” to “Specific security roles,” the change may take up to 24 hours to fully propagate, or for users to see the effect once they sign out and back in. (Microsoft Learn)

• The list of security roles shown for assignment is drawn from the root business unit. Business units lower in the hierarchy inherit these roles, so users in those units will effectively receive the same filtering. (Microsoft Learn)

• When selecting multiple views in bulk, only the first one can be edited via “View settings.” You’ll need to manage additional views individually. (Microsoft Learn)

Turning On the “Manage Table List Views” Feature

In addition to role-based view filtering, there is a “manage table list views” feature. When enabled:

• Users can choose their default view among the views the admin has allowed them to see. (Microsoft Learn)

• Users can manage (create, edit, share) their personal views via the Manage and share views option. (Microsoft Learn)

Note: this setting filters only the views shown in the table list view selector. Other views—such as in subgrids or associated grids—are not filtered out by this mechanism. (Microsoft Learn)

Best Practices & Considerations

• Start by auditing which views are actively used and by whom. Don’t lock down views that still serve broad purposes.

• Document which security roles should see which views. Over time, as roles evolve, revisit these assignments.

• Communicate changes to end users. If a view they used disappears (or appears), they should know why.

• Remember: this is a view-level visibility filter, not a data-level filter. Always align your role-based views with the record-level permissions defined in your security roles.

• Always test in a sandbox environment before applying to production.