How Microsoft Purview and Microsoft Fabric Work Together for Governance

Microsoft Fabric and Microsoft Purview are complementary, but they are not one governance product with two names. Fabric is the analytics platform where teams ingest, store, transform, model and consume data. Purview adds data-governance, information-protection and compliance capabilities across a wider estate.

The useful question is not whether Purview or Fabric "does governance". It is which control belongs at the tenant, domain, workspace, item, catalogue, information-protection and operating-model layers.

The division of responsibility

A practical split looks like this:

The third column is the one organisations underestimate. Software can represent roles and rules. It cannot resolve a disputed metric, make an executive accept risk, or require a domain owner to fix a recurring quality problem.

What governance is already inside Fabric

Fabric has native controls that should be designed before production data arrives.

Tenant administration

Fabric administrators manage settings that affect how the platform can be used across the organisation. Microsoft's Fabric administration overview groups the work around governance, security, administration and support. Tenant settings should be assigned deliberately, often to approved security groups rather than enabled broadly.

Domains and workspaces

Fabric domains allow workspaces to be grouped around business areas. This can support a federated model, but a domain name is not proof of ownership. Each domain still needs an accountable leader, workspace standards and a way to resolve cross-domain definitions.

Workspace roles are operationally powerful. Microsoft's workspace-role matrix distinguishes Admin, Member, Contributor and Viewer capabilities. Admin, Member and Contributor permissions can exceed what many consumers need, so do not use workspace membership as a convenient substitute for item-level and data-level design.

OneLake catalog, lineage and endorsement

The OneLake catalog helps users discover and manage Fabric items they can access. Fabric also supports lineage and endorsement patterns such as promoted and certified content. These features help users find the intended data product and assess its context.

They only work when teams maintain ownership, descriptions, certification criteria and release discipline. A catalogue full of unnamed lakehouses and stale semantic models is an inventory, not a trusted marketplace.

Information protection

Fabric supports sensitivity labels from Microsoft Purview Information Protection. The Fabric governance and compliance overview documents information protection, DLP, endorsement, lineage and related capabilities.

Coverage and behaviour can vary by Fabric item, workload, export path, tenant configuration and licence. Check the current Microsoft documentation for the specific scenario rather than assuming a label behaves identically everywhere.

What Purview adds

Microsoft Purview is a broader family of data governance, data security, risk and compliance solutions. Keep those solution areas distinct when scoping an implementation.

For data governance, Microsoft identifies two primary components:

• Data Map captures metadata from supported assets and sources.
• Unified Catalog provides a searchable, curated experience for data products, business concepts, access workflows, data quality and governance health.

Microsoft's data-governance overview makes two important points. The catalogue stores metadata rather than the underlying business data, and catalogue roles do not themselves grant access to that underlying data.

This means Purview can help a user discover a customer data product and understand its owner, description, lineage and quality. Access must still be enforced in the source and platform. That separation is healthy, but only if the operating process joins discovery, approval and technical provisioning.

Purview can also provide information-protection and DLP capabilities for supported Fabric scenarios. These are policy controls, not a blanket promise that every Fabric item, external source and downstream export is protected in the same way. Validate the supported item types and licensing during design.

How to design the two together

1. Start with business domains, not the org chart alone

Choose domains that reflect durable accountability for data, such as customer, finance, workforce or operations. Then identify shared concepts that cross those boundaries. "Customer" may be owned by one domain, but finance, service and sales can all depend on it.

Document who can approve a definition, certify a data product and accept a quality exception. Use a practical data governance framework to settle those accountabilities before assigning platform roles.

2. Establish the Fabric platform guardrails

Before broad onboarding, decide:

• Who may create capacities, domains and workspaces.
• How development, test and production are separated.
• Which tenant settings are enabled and for whom.
• How Entra groups map to workspace and item access.
• Which external sharing, export and service-principal scenarios are permitted.
• What must be logged, monitored and supported.
• How release and recovery work.

The aim is not to centralise every action. It is to make safe actions repeatable and risky exceptions visible.

3. Define minimum metadata

Set a small publication standard for production data products:

• Business purpose and intended users.
• Accountable owner and operational steward.
• Approved definitions.
• Source and lineage.
• Sensitivity and permitted use.
• Quality measures and last review date.
• Access-request path.
• Support contact and service expectation.

Automated metadata collection can reduce effort. It cannot write the business context reliably on behalf of the owner.

4. Connect classification to handling

A sensitivity label is useful only when people know what it means and systems apply the intended behaviour. Map each classification to access, sharing, export, retention and incident requirements. Test the paths users actually take, including Excel exports, APIs, notebooks and AI tools.

5. Operate certification and quality

Do not certify an asset forever. Certification should state criteria, approver, scope and review trigger. Quality measures should be tied to the use case. A field can be 99 per cent complete and still fail the one regulatory or operational decision that matters.

6. Test both allowed and denied access

For each role, confirm what the user can discover and what data they can open, query, export or share. Test service identities and AI agents as well as employees. Catalogue visibility and source access are separate tests.

A sensible implementation sequence

For a mid-market organisation, avoid launching an estate-wide catalogue before one valuable path works.

1. Select one domain and one important reporting, operational or AI outcome.
2. Inventory its source data, Fabric items, owners and consumers.
3. Set the tenant, workspace, identity and release controls.
4. Define the first data product and minimum metadata.
5. Configure the relevant Purview discovery, classification and policy capabilities.
6. Test lineage, quality, access, export and support scenarios.
7. Publish, measure adoption and fix operating gaps.
8. Reuse the pattern for the next domain only when it is supportable.

This sequence creates evidence about the operating model. It also limits catalogue work that nobody uses.

Common buying mistakes

Buying Purview to repair ownership

Purview can show a missing owner. It cannot make a business leader accept the role. Resolve the decision right and expected workload first.

Treating Fabric domains as security boundaries

Domains organise and delegate governance, but security still depends on tenant, workspace, item and data-level controls. Design each layer explicitly.

Applying labels without testing behaviour

A label name on an item is not evidence that every downstream path is controlled. Test supported behaviour and known gaps.

Cataloguing everything before proving use

High asset counts can look like progress while descriptions, quality and access workflows remain weak. Start with data products people need for a real decision.

Ignoring licence and operational cost

Purview and Fabric capabilities have separate licensing, capacity and operational implications. Confirm current entitlements and the work required to curate, monitor and support the controls.

Choose the next move

Move directly into a Microsoft Fabric implementation when the first domain, outcome, data, owners and control requirements are clear enough to scope.

Use a Data & AI Readiness Assessment when the platform decision is entangled with unresolved ownership, architecture, information-protection or AI-access questions. If the uncertainty is mainly organisational, external governance help is useful only when an independent specialist can accelerate a decision and transfer capability. Buying another tool will not resolve missing accountability.

Book a free 30-minute Data & AI consultation to determine whether the first governed Fabric outcome is ready for a defined sprint or needs focused readiness work.