Managing access to data, segmenting business operations, and aligning security policies with organizational structure are foundational to any enterprise software deployment. In Microsoft Dataverse—used by Power Platform and Dynamics 365—Business Units and Teams play a pivotal role in this access management model.
They define how data is segmented, who owns what, and what users can see and do within the system. Whether you’re managing a global sales organization, a multi-department service center, or building apps on Power Apps, understanding Business Units and Teams is critical to securing and scaling your solution.
This article covers the concept, structure, and best practices for using Business Units and Teams in Microsoft Dataverse, along with how they interact with security roles, user permissions, and hierarchical access.
What Are Business Units?
Definition
A Business Unit (BU) in Microsoft Dataverse represents a logical or functional partition within an organization. It mirrors your company’s organizational structure—such as departments, regions, or subsidiaries.
Business Units:
- Define data ownership boundaries.
- Act as containers for users, teams, and security roles.
- Are critical to the record-level security model in Dynamics 365 and Power Apps.
Note: Every environment must have a Root Business Unit, which is created by default and cannot be deleted or renamed.
Use Cases
- Global Enterprises: Separate operations by region—e.g., North America, Europe, APAC.
- Departments: Segment data access for Sales, HR, Finance, and Customer Support.
- Legal Entities: Partition data across subsidiaries or business entities.
Characteristics of Business Units
- Hierarchical: Business Units can have child units, allowing you to build a tree structure.
- Ownership-Driven: Each record belongs to a Business Unit via its owner (a user or team).
- Not for UI Navigation: Unlike folders, BUs don’t affect how users navigate—they purely govern access and ownership.
- Static Membership: A user belongs to one Business Unit at a time.
What Are Teams?
Definition
A Team in Dataverse is a group of users that can collaborate, share data ownership, and inherit security roles. Teams offer flexibility beyond the rigid one-to-one relationship users have with Business Units.
Teams allow:
- Cross-functional collaboration
- Shared record ownership
- Additional security roles
- Easier user management
Types of Teams
| Team Type | Description |
|---|---|
| Owner Team | Can own records like users do. Members get access based on the team’s security roles. |
| Access Team | Lightweight, for sharing specific records without needing roles. No record ownership. |
| Azure AD Security Group Team | Linked to Azure AD group for auto-membership. |
| Microsoft 365 Group Team | Tied to a Microsoft 365 group for collaboration and chat integration. |
Use Cases for Teams
- Assign ownership of records (e.g., service queue) to a team instead of a user.
- Create ad-hoc project teams that need temporary shared access to certain records.
- Define department-level roles without creating duplicate user permissions.
- Use Azure AD groups to sync team membership automatically.
Business Units vs. Teams: Key Differences
| Feature | Business Units | Teams |
|---|---|---|
| Structure | Hierarchical | Flat |
| Purpose | Security scope, data ownership boundaries | Collaboration and record access |
| User Membership | One per user | Multiple per user |
| Record Ownership | Yes (via users) | Yes (only for Owner Teams) |
| Security Roles | Assigned at BU level | Assigned directly to team |
| Flexibility | Low | High |
Summary: Business Units define the structure and boundaries; Teams enable flexible collaboration across those boundaries.
How They Work Together
Data Ownership
- Each record in Dataverse has an owner—either a user or an owner team.
- The owner’s Business Unit determines where the record belongs.
Access Inheritance
- A user inherits security roles from:
- Their assigned roles
- Teams they belong to
- Roles define what actions (create, read, write, etc.) users can take and at which access level (User, BU, Org).
Real-World Example: Sales Organization
Imagine a global sales team:
- Business Units:
- Root BU
- North America
- Europe
- Asia Pacific
- Root BU
- Users are assigned to their regional BU.
- Teams:
- “Enterprise Sales Team” (cross-region team for large deals)
- “Pricing Approval Team” (owner team that controls opportunity approvals)
In this setup:
- Data like leads and opportunities are owned by users or teams within their BU.
- Cross-regional collaboration happens through teams without compromising BU boundaries.
- Users inherit permissions based on both their personal role and team roles.
Security Implications
Access Level Scopes
When assigning security roles, permissions are scoped to:
- User – Records the user owns.
- Business Unit – Records owned by any user/team in the same BU.
- Parent: Child BU – Includes the user’s BU and all subordinate BUs.
- Organization – Full access across all BUs.
Example Scenario
- A Sales Manager in Europe BU with “Business Unit” access to Opportunities can:
- See opportunities owned by anyone in the Europe BU.
- Not see those in the Asia Pacific BU.
If the user is also part of a global “Enterprise Sales Team” that owns some opportunities:
- They can access those team-owned records, regardless of BU.
Managing Business Units and Teams
Admin Interface
You can manage BUs and Teams through:
- Power Platform Admin Center
- Make.PowerApps.com
- Dynamics 365 Settings > Security
Common Admin Tasks
- Creating child BUs for new departments or regions
- Moving users between BUs
- Assigning or cloning security roles
- Creating Owner Teams for shared records
- Setting up Access Teams for ad-hoc projects
- Using Azure AD group teams for auto-management
Best Practices
1. Design Your BU Structure Carefully
- Reflect your real org structure.
- Avoid excessive nesting; deep hierarchies can be hard to manage.
- Use BUs for security boundaries, not just visual grouping.
2. Use Teams for Flexibility
- Let users belong to multiple teams for cross-functional roles.
- Assign security roles to teams, not just users.
- Prefer Owner Teams for shared record ownership.
3. Avoid Frequent User Reassignments Between BUs
- Reassigning users resets their data access and can trigger ownership changes.
- Use Teams instead for temporary or lateral access.
4. Leverage Azure AD Group Teams
- Automate team membership using your organization’s existing identity infrastructure.
- Useful for auto-provisioning access based on roles.
5. Regularly Audit Roles and Team Membership
- Use PowerShell scripts or the Power Platform Admin Center to review access.
- Ensure least privilege principles are upheld.
Common Pitfalls
- Assigning users to the wrong BU, causing loss of access to records.
- Over-reliance on User roles, making permissions harder to manage across departments.
- Neglecting to define Owner Teams, leading to duplicate records or inconsistent access.
- Mixing up Access Teams and Owner Teams, which have very different behaviors.
Tools to Help
- Power Platform Admin Center: Manage BUs, Teams, and security.
- Security Role Inspector (XrmToolBox): Visualize effective permissions.
- Audit Logs: Track access changes and user actions.
- PowerShell & Admin APIs: Automate role assignments and access checks.
The Role in Power Apps and Custom Development
Even outside of Dynamics 365, model-driven apps built with Power Apps on Dataverse inherit this security model. That means:
- Developers can build secure apps without writing custom access logic.
- Admins can enforce org-wide data policies with BUs and Teams.
- Citizen developers can collaborate through Team access without IT involvement.
Future Outlook
Microsoft continues to evolve the security model in Dataverse:
- More granular permissions
- Environment-level isolation
- Managed Environments
- Security-aware Copilot prompts
- Azure AD conditional access
Business Units and Teams remain foundational components, but new features like security groups, DLP policies, and custom connectors will extend the platform’s flexibility and security in the years ahead.