Before any security tool in this course makes sense, you need one foundational idea: the business unit. It's an organizational container in Dynamics 365 CE — Microsoft's customer engagement (CE) suite of sales, service, and marketing apps — that groups users and records together, usually mirroring a company's real org chart.
Think "West Region" and "East Region," or "Sales" and "Support." A business unit is how the system represents those divisions, so everything built on top of it — security roles, teams, sharing — has a structure to work with.
- Every environment starts with one root business unit, created automatically
- Administrators add child business units underneath it to mirror real divisions
- Every user belongs to exactly one business unit at a time
- Most records inherit their business unit from whoever owns them
One department per floor
Picture business units as floors in an office building. Every employee has one floor as their home base. The building has structure too — maybe Support's floor reports up through the same chain as Sales' floor, or they're separate wings entirely.
That structure shapes who can naturally see into which areas — a theme that keeps returning once you reach security roles.
Every environment starts with one root business unit
When a Dynamics 365 CE environment is first provisioned, it comes with exactly one root business unit, typically named after the organization. Nothing needs to be created for this one — it exists on day one, and every user and record starts out belonging to it.
From there, an administrator creates child business units underneath the root to reflect real divisions. A child can itself have further children nested under it, forming a hierarchy:
- Ground floor: "Reception," the whole company's root business unit
- Second floor splits into "Sales" and "Support"
- The "Sales" floor further splits into "West Region" and "East Region" desks
The hierarchy connects business units to each other
Because business units nest, each one (other than the root) has exactly one parent. "West Region" sits under "Sales," which sits under the root.
This parent-child chain is what later lets a security role say "let this user see records anywhere in their business unit and every business unit underneath it" — the equivalent of a manager's keycard working on their own floor and every floor below it, without needing a separate card for each one.
| Concept | What it is | Building analogy |
|---|---|---|
| Root business unit | Created automatically with the environment; every user and record starts here | The building's ground floor / main entrance |
| Child business unit | Created under the root (or under another child) to reflect a real division | An individual floor, e.g. "Sales" or "Support" |
| Hierarchy | The parent-child chain connecting all business units in the environment | Which floors report up to which section of the building |
Records belong to a business unit too
It isn't just users — most records carry a business unit too, inherited from whoever owns them. A West Region rep's new Opportunity record files under West Region, the same way a folder made on the third floor lands in that floor's filing room, not somewhere else in the building.
This is what makes business units the backbone the rest of this course builds on. Once records and users both sit inside this structure, security roles can reference it directly to decide who sees what.