Multinational corporations implementing D365 Finance & Operations across business units often underestimate how much the environment strategy decision will shape the next decade of their ERP life. Each business unit operating in a different industry brings its own processes, regulatory compliance, and data sensitivities. Picking the wrong structure at the start is expensive to reverse.

Three patterns surface in architecture workshops. Each has advocates; only one scales.

The two corner cases that fail

Single instance with one unified legal entity for all business units. Appealing for simplicity: one configuration, one security model, one master data set. Breaks immediately when BUs have different:

• Fiscal calendars (calendar year vs fiscal year)
• Chart of accounts detail (manufacturing vs services have fundamentally different GL structures)
• Statutory reporting obligations (healthcare vs retail have distinct regulatory packages)
• Intercompany boundaries (unified LE can't intercompany with itself)

The appeal wears off in the first cross-industry consolidation discussion.

Separate tenant per business unit. Isolates BUs completely. Produces predictable problems:

• Cross-BU consolidated reporting becomes an Azure Synapse project
• Every tenant has its own license, its own upgrade schedule, its own admin overhead
• M&A that reorganizes BUs requires tenant migrations
• Economies of scale in shared configuration disappear

Teams propose this pattern when they're nervous about sharing environments. Usually the fear is solvable with security boundaries inside a shared tenant.

Custom integration layer merging outputs from separate D365 environments. Builds a new system to fix a problem the platform already addresses. Permanent ongoing cost; introduces a new source of truth; slows every new BU onboarding.

The pattern that scales

Single tenant, multiple legal entities, with business unit isolation via organization hierarchies and security roles.

The architecture:

• One D365 tenant hosting production + non-production environments
• One legal entity per BU (or one per BU-and-country if BUs operate in multiple countries)
• Country localization packages applied per LE as needed
• Organization hierarchies - Corporate → BU → Operating Unit → Department - supporting both financial reporting cuts and security boundaries
• Security roles scoped to BU via the organization hierarchy - a BU's users see only their BU's data despite sharing the tenant
• Shared master data where BUs share vendors or customers, via global address book; BU-exclusive master data configured per-LE
• Customizations in layered models - a Core model for shared logic, BU-specific models for industry variations, deployed together

The result: BUs operate with the independence they need, while corporate gets the consolidation, shared admin, and platform economics.

Organization hierarchy design

The hierarchy is how the tenant supports both financial and operational cuts:

• Financial reporting hierarchy: LE ↔ BU ↔ Division ↔ Corporate. Rolls trial balances up for consolidation.
• Operational hierarchy: LE ↔ BU ↔ Department ↔ Team. Drives security and workflow routing.
• Legal hierarchy: LE ↔ Parent LE ↔ Ultimate parent. For statutory ownership disclosures.

Multiple hierarchies coexist. Each serves a specific purpose. Conflating them into one is a common design error.

Security model with BU isolation

Security inside a shared tenant keeps BU data separate via:

• Legal entity scope on roles - a BU's accountants see only their LEs
• XDS (Extensible Data Security) policies - row-level filtering beyond LE (e.g., department scope within an LE)
• Organization hierarchy context in XDS - policies reference the user's BU via hierarchy
• Centralized roles for corporate functions - corporate finance, corporate audit, IT admin roles span all LEs with approval

This is more work than "just use separate tenants" but gives the single-tenant economics without compromising data boundaries.

Customization layering per BU

F&O's extension model supports layered customizations. The pattern:

• Foundation model - corporate-standard extensions that all BUs inherit (localization-specific tax extensions, centralized approval frameworks)
• Industry models - shared extensions per industry for BUs in that vertical (manufacturing extensions, retail extensions)
• BU-specific models - extensions unique to a single BU's needs

Each model version-controlled separately, deployed as a dependency chain. A BU's customization reaches them without polluting others.

ALM across BUs

With the multi-BU tenant, ALM has to support:

• Shared build pipeline for foundation and industry models
• Per-BU pipelines for BU-specific models
• Environment strategy - dev per BU for BU-specific work, shared sandboxes for integration testing, shared UAT for coordinated testing, production shared by all BUs

The build coordination is the new complexity. Usually addressed by a center-of-excellence team that owns foundation + industry models and coordinates release trains with BU teams.

When separate tenants is right

There are rare cases where separate tenants genuinely fit:

• Regulatory isolation required by law (certain defense or pharma scenarios)
• Data residency conflicts that can't be resolved within one tenant's regional deployment
• M&A scenarios where the acquired unit will eventually spin out
• Extreme size difference where the BU's scale warrants its own admin team

Each of these is rare. The default for multi-BU multinationals is single tenant, multi-LE.

What ships with the pattern

A working multi-BU D365 tenant has:

• Per-BU legal entities with appropriate localization
• Organization hierarchies for financial and operational cuts
• Security roles scoped to BU via hierarchy and XDS
• Shared master data framework with BU-specific release patterns
• Layered customization models (foundation, industry, BU)
• CoE governance for shared configuration
• ALM pipelines supporting the model layering

The pattern is boring because it's well-trodden. That's the point. Novel environment strategies are where multi-year regret accumulates.