Microsoft Dynamics 365 CE Business Units
Security
Dynamics 365 CE Security
Dynamics 365 CRM
Jun 7, 2025
Business Units
Business units (BUs) are the foundation of the Dynamics 365 CE security mode. They define the boundaries of data visibility and ownership across the organization. Every user, team, and record in the system is associated with a Business Unit.
What is Business Unit
A business Unit represents a logical partition of your organization within Dynamics 365.
It is not necessarily tied to a legal entity - rather, it is used to segment security and data visibility.
Examples of BU modeling:
Corporate divisions (Sales, Service, HR).
Regional branches (North America, EMEA, APAC).
Separate brands or business lines.
Every record (Account, Contact, Opportunity, etc.) belongs to a Business Unit via ownership. Every user belongs to exactly one Business Unit.
Business Unit Hierarchy
Dynamics 365 CE enforces a strict hierarchical model of Business Units.
The hierarchy starts from the Root Business Unit, created by default when the environment is provisioned.
Under the Root BU, you can create child Business Units. Each child can have its own child units, allowing multi-level nesting.
The hierarchy controls how access propagates: higher-level BUs can be granted access to lower-level BUs’ data through security role configuration.
User and Team assignment
A user belongs to only one BU at a time. This assignment controls which records the user can own and which security roles they can be assigned.
A team belongs to a specific BU as well as- with one exception: Access Teams(more on this later).
When a user is moved to a different BU:
All their security roles are removed.
They must be reassigned appropriate roles in the new BU.
This can impact their access and integrations - proceed with caution.
How Business Units affect Security
Security Roles in Dynamics 365 define privileges(Create, Read, Write, Delete, Append, Assign, Share) at different scopes:
None → No Access
User → Records owned by the user
Business Unit → Records owned within the user’s BU
Parent: Child Business Units → Records owned in the user’s BU and all child BUs
Organization → All records across the organization.
Scope | Access level |
|---|---|
None | No Access |
User | Records owned by the user |
Business Unit | Records owned within the user’s BU |
Parent: Child Business Units | Records owned in the user’s BU and all child BUs |
Organization | All records across the organization |
Example
Is a Salesperson has Read permission on Accounts at “Business Unit”level - they will only see Accounts owned in their BU.
If the permission is set to “Parent: Child Business Units”, they can also see Accounts in child BUs.
Common Pitfalls
Misusing BUs for reporting: BUs are a security concept, not a reporting structure. Don’t model BUs just to match org charts or for convenience in dashboards.
Too deep hierarchy: Overly complex BU hierarchies lead to difficult-to-maintain security and unexpected access issues. Keep the hierarchy as flat as possible.
Frequent user BU changes: Moving users between BUs disrupts their roles and can cause data access problems or errors in integrations. Consider using teams for flexible access instead.
Best Practices
Flat first - start with a simple BU hierarchy unless a clear business need exists for deeper nesting.
Security boundaries only - create a new BU only when true data segregation is required (e.g. legal, regulatory, regional).
Use teams for flexibility - for cross-BU collaboration, use Owner Teams or Access teams instead of moving users.
Plan ahead - BU hierarchy is hard to restructure once data and roles are heavily in use.
Related Articles
