Purview can deliver on its promise of a unified data governance platform, but some early architectural decisions are harder to unwind than they look. Here is what is worth thinking through before you start.
Microsoft Purview is a capable data governance platform. Automated scanning, business glossaries, data quality, lineage. The pitch is compelling and in our experience, it genuinely delivers, but only when the foundational architecture is thought through carefully upfront.
By the time a data governance implementation gets underway in a large organisation, a lot has already happened. Shared Microsoft tenants are in place. Multiple business units have different data maturity levels. A Fabric environment is already live. The IT operating model divides responsibilities in ways that do not map neatly onto a governance tool’s role structure.
Purview can work well in these environments, but the design approach needs to start with what the platform will and will not let you do.
Microsoft Purview enforces a rule that does not always surface prominently in early planning: each data source can only be registered once across the entire tenant. A data source must also be scanned within the same domain it was registered in.
In a single-organisation deployment this is unlikely to cause problems. In a shared Microsoft tenant, where multiple departments share the same Entra ID and Fabric environment, it becomes one of the most consequential design inputs you have.
If a shared Fabric instance is registered in Department A’s collection or domain, Department B cannot register it separately. This is a platform-level constraint, not a configuration choice.
The instinct in a multi-department environment is to give each department its own Purview domain: clean separation, clear ownership. Microsoft’s documentation describes this as a workable pattern for organisations with truly separate data sources. The challenge arises when departments share a Fabric tenant, which is increasingly common. In that scenario, a domain-per-department model either runs into the registration constraint or introduces a workaround where one department effectively becomes the gatekeeper for shared source scanning.
There is also a capacity consideration: Purview supports a maximum of five domains (one default plus four custom). In an environment with three or four departments, future growth or prod/non-prod separation can consume that capacity quickly.
In multi-department, shared-tenant environments, a single-domain, collection-based federation model is often more practical.
Shared data sources register once at the appropriate level in the hierarchy. Departments scope their scans downward into their own sub-collections, with scanned assets landing only where they should. Each department can manages their own scan configurations and curates their own assets without central team involvement in day-to-day operations.
The collection hierarchy is not just an organisational structure. It is also the permissions boundary for the Data Map. Roles assigned at a parent collection inherit downward to all child collections by default. This means the shape of your hierarchy directly determines who can see and do what.
A few things follow from this that are worth working through before you build.
First, the team that holds Collection Administrator at the root level has effective control over the entire structure. In a shared-services model this is usually the central IT or platform team, but it means that lower collection-level autonomy can depends on how that responsibility is delegated downward.
Second, restricting inheritance on a sub-collection is possible but has knock-on effects. It severs the permissions flow from the parent, which means every role must be explicitly assigned on that collection. For departments that want isolation from root-level control (root collection admin is always inherited), this is the mechanism.
Map your shared data sources first. Understanding which sources are shared across departments is the most important input to your collection hierarchy design. Everything else follows from that.
Consider domain capacity with growth in mind. The five-domain limit can feel distant at the start of a project but constrains quickly when prod/non-prod separation and future department onboarding are factored in.
Decide who holds root-level roles early. The root Collection Administrator and Data Source Administrator roles are the most consequential assignments in the platform. These should be named, agreed, and documented before any configuration begins.
Define your delegation model before you build. Decide upfront which departments will manage their own collections and sources, and which will rely on the central team. Trying to retrofit autonomy into a centrally managed structure is harder than designing for federation from the start.
Document the operating model, not just the architecture. A well-structured collection hierarchy with no clear ownership model will drift and degrade. A simpler structure with defined roles, documented responsibilities, and a repeatable onboarding process will grow in value.
If your business needs help, or is looking to get started with Microsoft Purview, get in touch with the One51 team.