Setting Up Fabric Governance: OneLake Catalog and Microsoft Purview, in the Right Order

The most common governance mistake in Microsoft Fabric is treating the OneLake catalog and Microsoft Purview as the same thing. They are not. They are two governance layers that do different jobs, and until you see them as distinct, you will keep setting up half a governance model and wondering why it does not hold.

The OneLake catalog is governance and discovery inside the Fabric estate. Microsoft now positions its Govern tab as the primary place to govern and administer Fabric data — items, workspaces, capacities, domains, ownership, endorsement, sensitivity and lineage, with recommendations to improve your posture. It answers: what Fabric data do we have, and how is it governed?

Microsoft Purview is broader enterprise data governance. Through its Data Map and Unified Catalog it catalogues, classifies and traces lineage across Fabric and other sources, with governance domains, a business glossary, data products and data quality. It answers: where does enterprise data live, how is it connected, and can the business discover and trust it?

Governance has nothing to govern until the estate exists. Before Purview, stand up the Fabric estate properly: separated workspaces for DEV, QA, UAT and PROD, and inside each, the medallion lakehouse — Bronze, Silver and Gold Delta tables — plus the semantic model, pipelines and, where you are heading toward agents, the ontology and Fabric Data Agent.

The OneLake catalog itself is part of Fabric — there is nothing to install. Open it and you get three experiences: Explore to discover data with search, tags and endorsements; Govern to understand and improve your governance posture; and Secure for centralised management of workspace and OneLake security roles. As a Fabric administrator, the Govern experience gives tenant-wide insight across items, workspaces, capacities and domains.

The work is not switching it on — it is curation. A catalog nobody has organised is just a list. The value comes from the tags, descriptions, ownership and domains you put on the items that matter, so that "does this dataset exist?" becomes a two-second search instead of a message to a colleague.

Here is the part most teams skip, and it matters more than any scan. Do not organise the Fabric estate only by technical team. Create business domains — Finance, Sales, Manufacturing, Supply Chain, HR, Customer, Operations — and nest the real data products under them: under Manufacturing, production data, machine data, quality data, inventory data, plant data.

Then assign ownership for every domain and important data product. A domain owner, a data product owner, a data steward and a technical owner — for Manufacturing, that might be the Manufacturing Director as domain owner, the Manufacturing BI Lead as data product owner, the data governance team as steward, and data engineering as technical owner. This is a data-domain operating model, and it is what makes governance stick.

This is the architectural heart of Fabric governance, and it is a business exercise, not a technical one. Scanning tables tells you what exists; domains and owners tell you who is accountable for it and what it means. Skip this and you have a searchable list with no one responsible for keeping it trustworthy.

Use the catalog’s Secure experience to manage access as three separate levels, not one. Workspace security decides who can access and manage a workspace (Admin, Member, Contributor, Viewer). OneLake security governs access to the data in OneLake. And data security — row-level security and object-level security — decides which rows and columns a user actually sees.

The flow is deliberate: a user passes through workspace RBAC, then OneLake security, then RLS and OLS, before reaching data. Layer sensitivity labels and access policies over that. The mistake to avoid is making everyone a workspace Admin or Contributor because it is quicker — that collapses all three levels into one and makes least privilege impossible to enforce later.

Design this in from the start. Retrofitting least privilege onto a live estate — where access has already been handed out broadly and sensitive data has already spread — is far harder than designing it, and it is usually forced on you by a failed audit rather than chosen.

With the Fabric layer governed, extend to the enterprise. In the Microsoft Purview portal, use the Data Map to register your Fabric tenant, then scan it to bring in metadata and lineage, including Power BI-related assets. For a same-tenant setup, evaluate a managed identity for authentication where your security model permits, add it to a dedicated Microsoft Entra security group, and grant that group the Fabric read-only admin API access.

Two Fabric admin-portal tenant settings commonly cause the scan to fail if missed: "Allow service principals to use read-only admin APIs", and "Enhance admin APIs responses with detailed metadata" — the latter is what lets Purview discover detailed Fabric dataset metadata automatically. After changing them, wait about fifteen minutes before registering and testing the scan.

Then create the scan, test the connection first, and run it — once or on a recurring schedule. Purview discovers workspaces, lakehouses (tables, columns, files), warehouses, semantic models, reports and dashboards, and the lineage between them. That lineage is what lets you answer the governance question that matters: if I change this source column, which reports break?

Metadata is not governance. The value comes from the business layer you build on top in Purview’s Unified Catalog. Start with a business glossary: define concepts like Revenue once — the definition, the business owner, the steward, related terms, and the data assets that carry it — so you stop relying on developers to explain what the data means.

Then publish data products. A data product such as "Manufacturing Sales Intelligence" bundles owner, business purpose, data assets, quality information, classification, documentation and consumers into something the business can discover and consume with confidence. This is the shift from a catalogue of tables to a catalogue of trusted, owned products.

Finally, classify sensitive data: mark customer identifiers as internal, names and contact details as personal, revenue and credit limits as confidential or highly confidential. Classification feeds security, data loss prevention, compliance, AI governance and safe data sharing — Microsoft’s own Fabric governance guidance calls out protecting sensitive data as part of the lifecycle, not an afterthought.

Do it in this order, every time: build the Fabric estate and medallion lakehouse; open and curate the OneLake catalog; create business domains and assign ownership; secure across workspace, OneLake and data levels; register and scan Fabric in Purview; then build the glossary, data products and classification. Get the order wrong — start with a Purview scan over an unorganised, unowned estate — and you catalogue chaos.

And hold the two layers distinct as you go. Use the OneLake catalog for in-Fabric discovery, endorsement and governance posture; use Purview for enterprise-wide classification, lineage and compliance across Fabric and beyond; and connect them. That distinction is what a Fabric solution architect is expected to draw, and it is the difference between a governance model that holds and one that quietly falls apart.

We build Microsoft-first by default. Where an estate also runs on Databricks, the same discipline applies with Unity Catalog as the governance plane — the tools differ, the order does not: unify, organise by domain, assign ownership, secure in layers, then catalogue and classify.