A security role is a named bundle of permissions assigned to a user, usually indirectly through their job function. For every table in the system — Account, Contact, Opportunity, and so on — a role spells out two things: which privileges a user has on that table, and how far each one reaches.
- A role defines up to seven privileges per table
- Each privilege carries its own access level, from None to Organization
- Access levels reach through the business unit hierarchy from the last chapter
- A user with multiple roles gets the most permissive combination of all of them
Privileges: what you're allowed to do
A privilege is a specific action on a table. Dynamics 365 CE breaks this into seven possible privileges per table:
| Privilege | What it means in plain terms |
|---|---|
| Create | Make a brand-new record |
| Read | Open and view an existing record |
| Write | Edit an existing record's fields |
| Delete | Permanently remove a record |
| Append | Attach this record to another record (e.g. link a Contact to an Account) |
| Assign | Hand ownership of a record to someone else |
| Share | Grant another user or team access to this specific record |
A role doesn't have to grant all seven for every table. A customer service role might get full Read and Write on Cases but no Delete — removing case history usually isn't something a rep should do casually.
Access levels: how far each privilege reaches
Having a privilege isn't all-or-nothing. Each one also carries an access level, which sets the scope of records it applies to — and this is where the business unit hierarchy from the last chapter comes back into play. From narrowest to widest:
| Access level | Scope |
|---|---|
| None | The privilege doesn't apply at all |
| User | Only records the user personally owns |
| Business Unit | Records owned by anyone in the user's own business unit |
| Parent: Child Business Units | Records in the user's business unit and every child business unit beneath it |
| Organization | Every record in the entire environment, regardless of business unit |
A keycard with a printed access level
Picture a security role as a keycard, and each privilege on it as one specific power the card grants — say, "open doors." Printed right next to each power is how far it reaches.
- Read: User — only opens your own office door
- Read: Business Unit — opens every door on your own floor, useless elsewhere
- Parent: Child Business Units — your floor and every floor below it in the org chart
- Organization — a master key, every door, every floor, no exceptions
Multiple roles: the most permissive one wins
A user is often assigned more than one role at once — a rep might hold both a general "Sales Rep" role and a narrower "Marketing Viewer" role. When roles overlap on the same privilege, Dynamics 365 CE doesn't average them or make you pick one.
It takes the most permissive access level across every role the user holds, privilege by privilege. Read at Business Unit on one role plus Read at Organization on another resolves to Organization — holding two keycards means you get to use whichever one opens more doors.
The next chapter looks at a second, additive way managers gain reach into their team's records — hierarchy security — before this course moves on to teams.