Business Units

Business Units in Dynamics 365 help the Department for Education (DfE) manage data access, security and organisational separation. A well‑designed Business Unit structure keeps systems simple, secure and easier to maintain.

What good Business Unit design looks like

For most DfE services, a simple and predictable Business Unit structure works best. Create Business Units only when there is a clear need for meaningful separation of data.

Do's

  • Use Business Units to separate areas with different security needs or regulatory responsibilities.
  • Keep the Business Unit hierarchy as flat as possible to reduce complexity.
  • Place users in the Business Unit that reflects where they do most of their work.
  • Use Teams and Security Roles to provide some flexible access as exceptions without moving users between Business Units.
  • Use organisation‑owned tables for shared DfE data such as Organisations (schools) or reference data used in lookups.
  • Review the Business Unit design every time a new serivce in onboarded or teams change.

Don'ts

  • Do not create a Business Unit for every DfE team or department.
  • Do not mirror the HR organisational structure using Business Units.
  • Do not move users between Business Units frequently, as this affects data access and record ownership (not just for that user but others as well).
  • Do not rely on Business Units for reporting purposes - use raw data for filtering instead.

Implications of the Business Unit structure

The way you design Business Units affects:

  • Security: Business Unit boundaries determine what users can see and do.
  • Maintenance: More Business Units increase administrative overhead for managing roles and teams and can become excessively complex on large applications.
  • Data ownership: User‑owned records remain within the user’s Business Unit unless explicitly reassigned.
  • Scalability: A simpler structure makes it easier to onboard new teams, directorates or services.

Examples

Example 1: Service-level separation

A service such as Teacher Services may operate within its own Business Unit because it manages sensitive teacher data that should not be visible to other DfE service areas.

Note, anyone in the Root Business Unit with a Security Role granting Organisation-level permissions would still see teacher data.

Example 2: Shared access across the department

Cross‑cutting roles, for example, data analysts or customer support teams - can access required data through Team membership rather than being placed in multiple Business Units.

Example 3: Avoiding unnecessary complexity

Instead of creating separate Business Units for areas such as Early Years, Further Education and Higher Education policy teams, use a single Business Unit and control access through Security Roles and record ownership.

Summary

Use Business Units sparingly and intentionally. Keep the structure simple, use teams for flexible access, and only create new Business Units when there is a clear security or operational need. This helps DfE maintain secure, consistent and scalable Dynamics 365 services.

Avoid complexity where possible.