Security roles

A security role in Dataverse and the Dynamics 365 CRM-side apps is a named bundle of privileges on tables (create, read, write, delete, append, append-to, assign, share), each with a scope that decides how far it reaches — user-owned records only, the whole business unit, a business unit and its children, or the entire organisation. Users are assigned one or more security roles, and their effective access is the union of every role assigned to them — there's no "deny" privilege that overrides a grant; access only ever expands as more roles are added, never contracts. Microsoft ships built-in roles — Salesperson, Customer Service Representative, System Administrator, and others — that customers copy and adjust rather than edit directly, so a platform update to the shipped role doesn't silently change what a customer's users can do.

In practice, the scope setting is where most access problems actually live, more than the privilege itself. A role granting "read" at organisation scope lets a user see every record of that type regardless of who owns it; the same privilege at business-unit scope restricts that to records owned within their own business unit — the difference between a call-centre agent seeing every customer in the company and seeing only their team's, using the exact same privilege checkbox. Getting the scope wrong in either direction causes real problems: too narrow and legitimate cross-team collaboration breaks; too wide and every user can see records that should have been restricted, an issue that often only surfaces during a security audit or, worse, an actual data-exposure incident.

Where confusion shows up: security roles are the coarse-grained layer, and people sometimes expect them to solve problems they're not designed for — hiding a specific sensitive field from most users, or sharing one particular record with someone who otherwise shouldn't see that table at all. Field-level security profiles handle the first case, and teams plus row sharing handle the second, layering finer-grained exceptions on top of the broad access a security role grants rather than trying to carve those exceptions into the role itself. Designing a clean role hierarchy up front is one of the most important Power Platform implementation tasks, and running an access audit at least annually — checking who has which role and whether that still matches their actual job — keeps a design that was clean at go-live from drifting into an unreviewable mess two years later.