What it does

A security role is a bundle of privileges. Each table privilege — Create, Read, Write, Delete, Append, Append To, Assign, Share — is granted at an access level that says how far up the business unit hierarchy it reaches. Roles attach to users, to owner teams, and to Entra group teams.

Key facts

• Privileges are cumulative. A user gets the union of every role assigned to them directly and every role on every team they belong to, and the widest grant wins. There is no deny.
• Access levels are Organization, Parent: Child Business Unit, Business Unit, User and None. Each level implicitly includes the ones below it.
• Organisation-owned tables, miscellaneous privileges and privacy-related privileges only offer Organization or None. There's no middle ground.
• Roles have a Member's privilege inheritance setting: Team privileges only means the user can only use the privilege on rows the team owns; Direct User (Basic) access level and Team privileges is the default for new roles and lets them use it on their own rows too.
• Privilege types split across three tabs: Tables, Miscellaneous (non-record tasks like publishing articles or activating business rules) and Privacy-related (export to Excel, print).
• Copy table permissions copies settings from one table to many. If a source permission's depth doesn't exist on the target, the copy fails with an error; permissions present on the target but absent from the source keep their existing depth.
• Predefined permission setting groups — No Access, Full Access, Collaborate, Private, Reference, Custom — are a fast way to set a whole table at once, and they overwrite whatever was there.
• Microsoft's own recommendation is to build new roles by copying a predefined template: App Opener for the minimum needed to run an app, Basic User for the minimum plus core business tables.
• System role descriptions, applies-to and summary fields can't be edited.

When to use / skip

Roles are not optional — a user with no role can't do anything. The judgement call is how many you build. A role per job function, layered so most people get one or two, ages far better than a role per person or a role per department per app. Resist the urge to clone a role every time someone needs one extra privilege; that's how you end up with forty near-identical roles nobody dares change. Build small composable roles for cross-cutting capabilities (export, bulk delete, admin functions) and assign them alongside a base role.

Configuration decisions

• Whether roles map to job functions or to applications, and whether a user is expected to hold one role or several stacked.
• Access level per privilege per table, which is the actual security design and deserves a signed-off matrix.
• Privilege inheritance setting on any role assigned to a team, because it changes what team members can do with their own rows.
• Whether roles are assigned directly, through owner teams, or through Entra group teams — and picking one as the default pattern.
• Which base template you copy from, since starting from a blank role usually means forgetting the plumbing privileges.

Gotchas

• The union rule catches everyone. Once you've granted organisation-level Read on a table through any role or team, you can't claw it back for a subset of rows with a narrower role. The only fix is removing the wide grant.
• Over-granting to make an error go away is the most common administrative failure. It's fast, it works, and within a year the model is unrecognisable.
• Miscellaneous and privacy privileges are easy to overlook and are where "why can't they export?" and "why can they export?" both come from.
• Copy table permissions overwrites the target completely. Used carelessly across a multi-select of tables it's very hard to undo.
• Roles assigned to a team behave differently depending on the inheritance setting, and the setting lives on the role, not the team. Two teams sharing a role share the behaviour.
• Roles belong to a business unit. A role assigned from the wrong business unit grants access to the wrong data, and the role name gives no clue.

Consultant notes

• Insist on a written privilege matrix as a design deliverable — tables down the side, roles across the top, access levels in the cells. It's the only artefact that makes the model reviewable by anyone other than the person who built it.
• Explain the union rule to the client in plain terms early: security here adds up, it never subtracts. It reframes every subsequent request.
• Ship roles in a solution and treat them as code. Manually recreating roles per environment is how test and production drift.
• When a user reports missing access, resist adding a privilege until you've used Check Access on the row. Half the time the privilege is fine and the problem is business unit or ownership.

---

Worth revisiting when the security role editor changes again, or if Dataverse ever gains explicit deny semantics.