Dynamics Community Forum Thread Details

Single-BU vs Multi-BU Setup

We want to set up Dynamics 365 Sales for an international sales organization. It is organized by Sales Regions. Some Sales Regions have Sub-Clusters. Legally the company does not must separate data.
They have VP Global Sales, Regional Sales Heads, Sales Reps, reporting in a straight line (Sales Rep > Regional Sales Head > VP Sales). Additionally, there are some global positions, like Product Managers, Technical Mangers, Business Development Managers.

Account Owners must have a 365-view of their owned accounts, contacts, leads. Certain fields (e.g. price information) must only be visible to the owner/creator and its managers.
They also have Key Account Management with local key accounts in several Sales Regions. They must roll up to Global Key Accounts. Local Key Account Managers must have full visibility of the Global Key Account their local KA belongs to. Apart from that, almost every user will have org-wide (read, write) permissions. It is meant to be an open, collaborative setup.

Question: Would you set it up with a single or multiple BU and why? Would you recommend Manager or Position Hierarchy?

Any advice, recommendation, or comment is much appriacted.

Thanks

Categories:

Dynamics 365 Sales

For your scenario, I would recommend using a single Business Unit (BU) along with a Manager Hierarchy as the primary approach, and optionally a Position Hierarchy for specific cross-functional roles.

Let’s break it down and give you a practical architecture recommendation.

Business Unit (BU)

Use Single BU
Reason:
- No legal data separation required
- Organization wants open collaboration
- Easier to manage and maintain

Hierarchy

Use Manager Hierarchy (Primary)
- Fits your reporting structure (Sales Rep → Regional Head → VP)
- Automatically gives managers access to their team’s data
Use Position Hierarchy (Optional)
- Only for cross-functional roles (Product Managers, Technical Managers, etc.)
- When access is not based on reporting line

Data Access

Most users: Org-level read/write access
Sensitive fields (e.g., pricing):
- Use Field Security Profiles
- Visible only to owner + managers

Key Account Management

Use Account Hierarchy (Parent–Child Accounts)
- Global Account → Parent
- Local Accounts → Child
Ensures:
- Local teams can see Global Account

Regions / Sub-Clusters

Do NOT use BUs
Use:
- Fields (Region, Sub-cluster)
- Optional Teams

Overall, this approach keeps the system simple, scalable, and aligned with your collaborative business needs while still maintaining control over sensitive data.

Quick Links

Subscribe to this forum!