Security roles for apps

What it does

Dataverse security roles do two separate jobs for apps: they decide who can open a model-driven app at all, and they decide what data any app — canvas or model-driven — can read and write once it's open. Those two jobs are frequently confused, and most access problems on a project are the second one being blamed on the first.

Key facts

Roles are cumulative. A user with three roles gets the union of all three privileges, and there's no way to subtract. There's no deny.
Table privileges are Create, Read, Write, Delete, Append, Append To, Assign and Share. Each has an access level: Organization, Parent: Child Business Unit, Business Unit, User, or None.
Append and Append To are a pair. To attach a note to an opportunity you need Append on the note and Append To on the opportunity. For many-to-many, you need Append on both tables.
Permission Settings give you named bundles per table — No Access, Full Access, Collaborate (read all, edit own), Private (own only), Reference (read only) — which is faster than clicking eight privileges.
Member's privilege inheritance matters: Team privileges only means the user acts through the team and records are team-owned; Direct User (Basic) access level and Team privileges is the default for new roles and lets users own records themselves.
Predefined starting points: App Opener has the minimum privileges to run an app. Basic User adds the core business tables. Both are meant to be copied, not edited.
Canvas apps that talk to Dataverse are still gated by security roles for the data, even though the app itself is gated by sharing.
Organization-owned tables, miscellaneous privileges and privacy-related privileges only offer Organization or None — there's no business unit granularity there.
Copying table permissions from one table to many fails on a target table if the source's access-level depth doesn't exist there. It doesn't silently downgrade.

When to use / skip

There's no skip. Anything touching Dataverse needs a role design, and the only real decision is how much of it you do properly. For a model-driven app, one custom role per functional persona, copied from App Opener or Basic User and built up, is the pattern that survives a year. For a canvas app over Dataverse, you still need the same thinking even though the app-level share makes it feel optional. Where you can genuinely economise is business unit hierarchy — if the client has one business unit and always will, don't design as though they have twelve.

Configuration decisions

Whether access follows the business unit hierarchy or is flat with User-level ownership plus teams. Getting this wrong is expensive to undo because it's baked into every role.
Whether roles are assigned to individuals, to Dataverse teams, or through Entra group teams. Group teams are the maintainable answer for anything above a handful of users.
Which persona roles exist, and whether each one is a copy of a template or an edit of a system role. Copies survive updates; edits to predefined roles may not.
Whether privacy-related privileges (Export to Excel, print, bulk delete) are granted, since these are the practical data-exfiltration routes inside an app.
Whether canvas app share is itself gated by the Canvas App Share privilege in the environment.

Gotchas

App-level access and data-level access are different failures with the same symptom. If a user can't see the app in the app list, that's the app role assignment. If they see the app but every view is empty, that's table privileges. Diagnose in that order.
System updates can wipe customisations to predefined roles, including Environment Maker. Anything you've hand-edited on a system role should be documented and rechecked.
Users with the Environment Maker role can run model-driven apps without a licence, which quietly makes "just give them Environment Maker" look like it works while creating a governance hole.
Granting Read at Organization level on a table nobody thought about — often a lookup or config table — is how a role designed for one team ends up exposing everything.
A user must exist in the environment, not just in Microsoft 365. Assigning a role to someone who has never been synced into Dataverse does nothing visible.

Consultant notes

Insist on a role matrix as a signed-off artefact: persona down the side, table across the top, privilege and depth in the cells. It's tedious and it's the only thing that makes a security review survivable.
Use the Check Access feature when someone reports a permission problem, rather than diffing roles by eye.
Warn the client that adding a role is easy and removing one is a regression test. Cumulative privileges mean nobody ever notices an over-grant until an audit does.
Push back hard on System Administrator as a workaround. Every project has the moment where it's proposed "temporarily", and it's never temporary.

Worth revisiting if app-level security roles for canvas sharing become the default experience, or after any wave that changes the role editor.