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:

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:

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.

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

1. Flat first - start with a simple BU hierarchy unless a clear business need exists for deeper nesting.

2. Security boundaries only - create a new BU only when true data segregation is required (e.g. legal, regulatory, regional).

3. Use teams for flexibility - for cross-BU collaboration, use Owner Teams or Access teams instead of moving users.

4. Plan ahead - BU hierarchy is hard to restructure once data and roles are heavily in use.