Every building block covered so far — business units, security roles, hierarchy security, and teams — exists to answer one question for one person at a time: what can this specific user actually do? This chapter pulls those pieces together at the user record itself, where they all attach.
Becoming a user
A person becomes a Dynamics 365 CE user when an administrator creates a user record for them and assigns them a license — the subscription entitlement that lets them sign in and use the app at all.
Licensing is its own topic with its own tradeoffs, already covered conceptually in the Licensing Basics chapter of the Get Started course. This chapter assumes the license question is settled and focuses on what happens next: how a user's actual access gets built.
Net access is a sum, not a single setting
There's no one dial that sets a user's access. What a user can actually see and do is the sum of several things layered on top of each other:
| Source | What it contributes |
|---|---|
| Direct security role(s) | Privileges and access levels assigned straight to this user |
| Business unit membership | Where the user sits in the org hierarchy, which anchors "Business Unit" and "Parent: Child Business Units" access levels |
| Hierarchy security | Extra read/limited-write reach a manager gets into their reports' records, if enabled |
| Team memberships | Any additional roles or record access inherited from owner teams or access teams the user belongs to |
- A user needs a license before any of these sources matter at all
- Net access is additive — nothing here competes with or overrides another source
- Moving a user between business units can change their effective access instantly
- Copying an existing user's setup for a new hire often gets one of these sources wrong
A hotel guest's all-access wristband
Think of a hotel guest checking in for a conference. They're handed an individual room key — that's their direct security role. If they're attending a group event, they might also get a wristband granting entry to the pool — that's a team membership layering extra access on top. And which floors the elevator will even let their key reach is set by which wing of the hotel they're staying in — that's the business unit.
None of these arrives alone. The guest's actual, practical access around the building is the combination of all of them at once.
Why this layered view matters
Troubleshooting "why can't this user see that record" almost always means checking every source, not just one. A role might look correctly scoped, but a business unit move, or a missing team membership, can change effective access just as much as the role itself.
This also explains why moving a user between business units is a bigger change than it looks. Suppose Priya later transfers from Support into Sales. Her "Support Agent" role doesn't disappear — but the Business Unit-scoped Cases it grants now resolve against Sales instead of Support, since that access level was always relative to wherever she currently sits.
Her VIP Escalations team membership, by contrast, keeps working exactly as before, since Organization-level access from a team doesn't care which business unit its members belong to. Seeing the sources separately is what makes a change like this predictable instead of surprising.
The same layered view matters the moment someone new joins the company. Setting up a new hire well means deliberately choosing each piece — business unit, role, teams, and whether hierarchy security applies to them as a manager — rather than copying one existing user wholesale. A new Sales hire copied from an existing Support user would inherit the wrong business unit entirely, no matter how correct their role looks on its own.