---
title: "Microsoft Fabric Governance: What's Built In and What You Add"
url: "https://atlan.com/know/ai-agent/microsoft/microsoft-fabric-governance/"
description: "Microsoft Fabric governance runs on OneLake catalog and Purview. Here's what they cover natively, where coverage stops, and what a Microsoft-first estate adds."
author: "Emily Winks"
author_role: "Data Governance Expert"
published: "2026-09-29"
updated: "2026-09-29T00:00:00.000Z"
---

> Atlan is hosting Context Conference, bringing together the leaders and builders at the frontier of giving AI the context it needs to understand their business. It runs online on October 28, 2026, from 11:00 AM to 2:00 PM ET. Atlan co-founder Prukalpa Sankar opens and closes the day. Leaders from AstraZeneca, BNY and Verizon share why they invest in context and what they get from it. Registrants get early access to The AI Context Gap, a new study from MIT Technology Review Insights. Register: https://atlan.com/context-conference/

---

OneLake catalog and Microsoft Purview give a Fabric tenant real, well-built native governance: four pillars (manage, protect, discover, monitor), sensitivity labels and DLP with real teeth, and lineage that's solid as long as it stays inside Fabric. The moment your estate runs a workload Microsoft doesn't own, that native coverage runs out. Atlan, Databricks, and Snowflake are the names that come up next in that conversation: Fabric and Purview handle the Microsoft-native layer, and a cross-platform context layer like Atlan carries lineage and ownership across the handoff to everything else. What follows covers what's built in, where native coverage stops, and what a Microsoft-first estate typically adds beyond it.

### What Governance Tooling Are You Still Missing?

Maps your obligations against what Fabric and Purview already cover, and names the actual capability gap instead of a generic governance checklist. [Read the skill](/skills/governance-tool-fit.md).

*Paste into a new chat*

```
Use the skill at https://atlan.com/skills/governance-tool-fit.md to work out which AI governance capability your Fabric and Purview stack still leaves uncovered. Ask me for whatever it needs.
```

*Run once in a terminal*

```
curl -fsSL --create-dirs \
  -o ~/.agents/skills/governance-tool-fit/SKILL.md \
  https://atlan.com/skills/governance-tool-fit.md
```

*For an agent*

```
curl -fsSL https://atlan.com/skills/governance-tool-fit.md
```


    Human
    Agent


  ClaudeChatGPTGeminiCursorOther
  Copy

.skp{margin:1.75rem 0;padding:1rem 1.125rem 1.125rem}
.skp h3{margin:0 0 .375rem!important;font-size:20px!important;line-height:24px!important;
 font-family:var(--font-funnel-display)!important;font-weight:600!important;color:#2B2B39!important}
.skp > p{margin:0 0 .875rem!important;font-size:14px!important;line-height:22px!important;color:#555572!important}
.skp > p a{color:#2026D2;text-decoration:underline}
.skp-box{margin-bottom:.75rem}
.skp-p em{display:block;font-size:10px;font-weight:700;letter-spacing:.06em;text-transform:uppercase;
 color:#F34D77;font-style:normal;margin-bottom:.25rem}
.skp-p > p{margin:0!important}
#seo-layout article .skp .skp-p pre{margin:0!important;overflow-x:auto}
#seo-layout article .skp .skp-p pre code{color:#2B2B39!important;font-size:12px!important;line-height:19px;
 white-space:pre-wrap;overflow-wrap:anywhere;background:none;padding:0;
 font-family:ui-monospace,SFMono-Regular,Menlo,monospace}
.skp-p + .skp-p{margin-top:.625rem}
.skp-cs{display:flex;flex-wrap:wrap;align-items:center;gap:.375rem}
.skp-seg{display:inline-flex;flex:0 0 auto;border:1px solid #DDDDE3;border-radius:999px;overflow:hidden;background:#fff}
.skp-m{min-height:32px;padding:.25rem .75rem;border:0;background:transparent;font-family:inherit;color:#77778E;cursor:pointer}
.skp-m:hover{color:#2026D2}
.skp-m.on{background:#2026D2;color:#fff}
.skp-sep{flex:0 0 auto;width:1px;height:20px;background:#DDDDE3;margin:0 .25rem}
.skp-tools{display:inline-flex;flex-wrap:wrap;gap:.375rem;min-width:0}
.skp-cp{margin-left:auto;min-height:32px;padding:.25rem .75rem;border-radius:999px;background:#fff;
 font-family:inherit;color:#555572;cursor:pointer}
.skp-cp:hover{border-color:#2026D2!important;color:#2026D2}
.skp-cs .skp-c{display:inline-flex!important;width:auto;flex:0 0 auto;align-items:center;gap:.375rem;
 min-height:32px;padding:.25rem .625rem;border-radius:999px;background:#fff;font-family:inherit;
 color:#555572;cursor:pointer}
.skp-cs .skp-c img{display:block!important;width:14px!important;height:14px!important;
 max-width:14px!important;flex:0 0 auto;opacity:.55;margin:0}
.skp-c:hover img,.skp-c.on img{opacity:1}
.skp-cs .skp-c:hover{border-color:#797DE4!important;color:#2026D2}
.skp-cs .skp-c.on{border-color:#2026D2!important;background:#F4F4FD;color:#2026D2}
.skp-agent .skp-tools,.skp-agent .skp-sep{display:none}

(function(){
  var p=document.querySelector('.skp[data-skill="governance-tool-fit"]');if(!p)return;
  var panes=p.querySelectorAll('.skp-p');
  function show(id){panes.forEach(function(x){x.hidden=x.dataset.skp!==id;});}
  function cur(){var a=p.querySelector('.skp-p:not([hidden]) pre code');return a?a.textContent:'';}
  show('prompt');
  p.querySelectorAll('.skp-p em').forEach(function(e){
    var par=e.parentElement;
    ((par.tagName==='P'&&par.textContent.trim()===e.textContent.trim())?par:e).hidden=true;
  });
  p.querySelectorAll('.skp-c').forEach(function(b){
    b.addEventListener('click',function(){
      p.querySelectorAll('.skp-c').forEach(function(x){var on=x===b;x.classList.toggle('on',on);x.setAttribute('aria-pressed',on);});
      show(b.dataset.skp);
    });
  });
  p.querySelectorAll('.skp-m').forEach(function(m){
    m.addEventListener('click',function(){
      var agent=m.dataset.skpMode==='agent';
      p.classList.toggle('skp-agent',agent);
      p.querySelectorAll('.skp-m').forEach(function(x){var on=x===m;x.classList.toggle('on',on);x.setAttribute('aria-pressed',on);});
      if(agent){show('agent');}else{var s=p.querySelector('.skp-c.on');show(s?s.dataset.skp:'prompt');}
    });
  });
  var c=p.querySelector('[data-skp-copy]');
  c.addEventListener('click',function(){
    navigator.clipboard.writeText(cur()).then(function(){
      c.textContent='Copied';setTimeout(function(){c.textContent='Copy';},1600);
    });
  });
})();

---

Microsoft ships a lot before you add anything. OneLake catalog gives every Fabric user a searchable, permission-scoped view of workspaces, lakehouses, and reports, and Purview layers organization-wide DLP, sensitivity labels, and compliance scanning on top. That's a genuinely capable starting point, and most of what follows in the [Purview Data Map, Unified Catalog and Information Protection](https://atlan.com/know/ai-agent/microsoft/purview-unified-catalog/) guide still applies unchanged.

Three things reliably need more, once an estate grows past a single Fabric tenant:

- Lineage that has to survive the handoff between Fabric and Power BI, or between Fabric and a non-Microsoft warehouse
- A catalog and glossary that cover Databricks, Snowflake, BigQuery, Redshift, or file shares, none of which OneLake catalog reaches
- Governance workflows that get adopted by people outside the data team, not just configured once and left alone

| What it is | Key benefit | Best for | Native tools it works alongside | Core components |
|---|---|---|---|---|
| Native Fabric/Purview governance | No setup cost; ships with the tenant | Single-tenant, Microsoft-only estates | OneLake catalog, Admin Portal | Four pillars, sensitivity labels, DLP, workspace roles |
| Cross-platform context layer (Atlan) | Lineage and ownership survive platform handoffs | Estates running Fabric plus Databricks, Snowflake, or other systems | Fabric, Purview, non-Microsoft warehouses | Metadata catalog, column-level lineage, glossary, Entra ID/APIM auth |

---

## What is Microsoft Fabric governance?

Microsoft Fabric governance is the combination of OneLake catalog and Microsoft Purview that lets a Fabric tenant manage, protect, discover, and monitor its own data, according to [Microsoft's own governance documentation](https://learn.microsoft.com/en-us/fabric/governance/). Those four pillars are Microsoft's framework, not a third-party interpretation of it, and they cover a real, well-built range of native capability before anyone adds a separate tool. OneLake catalog handles day-to-day discovery inside Fabric, while Purview extends the same tenant with organization-wide policy, DLP, and sensitivity labels that Fabric alone doesn't provide.

### The four pillars: Manage, Protect, Discover, Monitor

**Manage** covers the tenant, domain, and workspace hierarchy that decides who administers what. **Protect** applies sensitivity labels and Data Loss Prevention policies so sensitive data doesn't leave Fabric unnoticed. **Discover** is OneLake catalog's job: search, metadata, and lineage for items you already have access to. **Monitor** covers Fabric's own audit trail and usage reporting, surfaced through Purview Audit for Fabric activities. Together, these four pillars are Microsoft's complete native governance story, and a Microsoft-first team can run entirely inside them for a long time before feeling a gap.

### OneLake catalog vs Purview at a glance

OneLake catalog is the in-product, day-to-day experience: fast search, filtering, and metadata visibility without leaving Fabric, scoped to items the viewer can already see, and covered in more depth in [OneLake catalog](https://atlan.com/know/microsoft-fabric/onelake-catalog/). Purview operates at a different level entirely, adding organization-wide visibility (including into items a user doesn't yet have access to), a business glossary, and governance domains that map ownership across the enterprise, much closer to what a general-purpose [data catalog](https://atlan.com/what-is-a-data-catalog/) or an [AI data catalog](https://atlan.com/ai-data-catalog/) aims for. The full comparison, including where a cross-platform layer fits alongside both, follows in the next section.

Fabric's native pillars answer "is this data managed inside my Fabric tenant," which is a real and necessary question. It isn't the same question as "is this data governed the same way everywhere it lives," and that second question is where a cross-platform context layer earns its place alongside, not instead of, the four pillars.

---

## How Microsoft Fabric governance works, from tenant to workspace

Fabric's governance hierarchy runs from tenant settings down through domains to individual workspaces, and setting it up correctly is mostly an admin-portal exercise Microsoft already documents well.

The tenant Admin Portal is where governance starts: tenant-wide settings, domain creation, and the OneLake metadata scanning that populates OneLake catalog in the first place. Domains group related workspaces under a single owner, so a business unit or region can set its own policies without every workspace needing central IT's direct involvement. Workspace-level roles (Admin, Member, Contributor, Viewer) then control who can view, edit, or administer a given workspace, and those roles matter beyond day-to-day access: workspace role also determines what a downstream lineage tool can extract, detailed further down in the Scanner API mode trade-off table.

### Where native setup documentation lives

Microsoft's own [governance and compliance overview](https://learn.microsoft.com/en-us/fabric/governance/governance-compliance-overview) covers domain setup, tenant settings, and workspace roles in more procedural detail than needs repeating here, and the [Power BI data catalog setup guide](https://atlan.com/how-to/microsoft-power-bi-data-catalog-setup-guide/) walks through the semantic-model side of the same estate. [Power BI governance at enterprise scale](https://atlan.com/power-bi-data-governance/) covers what changes once multiple workspaces are involved. What matters more is what happens once that native setup is in place: what it covers, and what it doesn't.

---

## OneLake catalog vs Purview Unified Catalog: what's the difference?

OneLake catalog is Fabric-scoped and permission-bound; Purview's Unified Catalog is organization-wide, reaching policy and compliance across Azure, AWS, GCP, and on-prem sources, not just Fabric. Most comparisons stop there, treating the decision as two-way, OneLake or Purview, when a growing number of estates need a third option neither one is built to be, the distinction covered in [data catalog vs context layer](https://atlan.com/know/data-catalog-vs-context-layer/) and, for teams already weighing active metadata investments, [active metadata vs context layer](https://atlan.com/know/active-metadata-vs-context-layer/).

OneLake catalog's Explore, Govern, and Secure tabs cover discovery, stewardship recommendations, and access auditing for items the current user can already see inside Fabric, and OneLake catalog's own external catalog federation extends discovery to [Databricks Unity Catalog and AWS Glue](https://kanerika.com/blogs/microsoft-fabric-onelake-catalog/), though that specific feature is still in preview as of 2026, not yet something a production governance architecture should depend on. Purview goes further on the policy side: organization-wide visibility into assets a user doesn't yet have access to, a shared business glossary, and governance domains that assign ownership at scale, layered on top of Fabric rather than duplicating what OneLake catalog already does inside it.

| Dimension | OneLake catalog | Microsoft Purview | Cross-platform context layer (Atlan) |
|---|---|---|---|
| Scope | Fabric items the viewer can already see | Organization-wide, including items not yet accessible to the viewer | Fabric plus non-Microsoft systems in the same graph |
| Primary strength | Fast, in-product discovery | DLP, sensitivity labels, compliance scanning | Lineage and ownership that survive a platform handoff |
| Lineage reach | Fabric-scoped, permission-bound | Scoped to what enters Fabric; doesn't trace upstream on its own | Column-level lineage from source through Fabric into semantic models and reports |
| Non-Microsoft systems | External catalog federation to Unity Catalog and AWS Glue, still in preview | Scans hybrid and multi-cloud sources for DLP and compliance; not the same mechanism as catalog federation | Databricks, Snowflake, BigQuery, Redshift natively cataloged |
| Adoption/stewardship | Recommendations surfaced in-product | Glossary exists but isn't auto-populated | Ownership and glossary terms connected across systems |
| Access model | Inherits Fabric workspace permissions | Centralized policy, access-request workflows | Metadata-only, read-only today |

An estate that also runs Databricks, Snowflake, or file shares Purview doesn't reach the same way it reaches Fabric needs that third column. That isn't a knock on either native tool. It's the shape of a Microsoft-standardized estate that grew past a single platform, which describes most enterprise data estates a few years into their cloud journey.

### Where the two-way framing breaks down for a multi-platform estate

Asking "where did this number come from" for a report touching a non-Fabric warehouse is where neither OneLake catalog's still-maturing external federation nor Purview's own cross-platform reach answers completely on its own. [Microsoft's own governance documentation](https://learn.microsoft.com/en-us/fabric/governance/) implies the same boundary: lineage tracking begins when data enters Fabric, not before. [Purview vs Databricks Unity Catalog](https://atlan.com/know/purview-vs-databricks-unity-catalog/) and [Microsoft Fabric vs Azure Synapse](https://atlan.com/microsoft-fabric-vs-azure-synapse/) cover two common seams this shows up at.

---

## Where native Fabric and Purview governance stops

Fabric and Purview do a lot well: the four pillars, DLP, sensitivity labels, and Fabric-scoped lineage are real, working capability. Native coverage still stops at three specific, evidence-backed seams: the Fabric/Power BI lineage boundary, cross-platform federation that's still maturing, and adoption that Purview doesn't automate on its own. None of these are product failures. They're the natural edge of tools built primarily for a Microsoft-native estate.

### Lineage that stops at the Fabric/Power BI boundary

James Serra, Data & AI Solution Architect at Microsoft, put this plainly in his own comparison of OneLake catalog and Purview: "Fabric lineage is mostly scoped within Fabric, not across the full data estate." His post goes further, noting that OneLake catalog's discovery is "primarily permission-scoped," showing only items a user already has access to rather than a full picture of the organization's data. Independent practitioner reports on Reddit corroborate the pattern from the other direction: teams describe needing manual API integration to expose Power BI lineage, and lineage retrieval from Fabric Spark that's snapshot-based rather than historical, so a lineage graph captured today doesn't automatically reflect what changed last week. For the deeper, source-to-visual mechanics of where this specific boundary sits, see the practical read on [Power BI's semantic model](https://atlan.com/know/ai-agent/semantic-layer/power-bi-semantic-model/).

### Cross-platform federation is still maturing

The ambition to cover non-Microsoft platforms is real on both sides of the native toolset, but independent analysis of Fabric governance tooling describes [OneLake catalog's own external catalog federation into Unity Catalog and AWS Glue as still in preview](https://kanerika.com/blogs/microsoft-fabric-onelake-catalog/), not a production-ready substitute yet. Purview's own multi-cloud reach runs through a different mechanism, scanning hybrid and multi-cloud sources for policy and DLP purposes, which is real but isn't the same thing as a unified catalog federation. That gap doesn't close on its own timeline just because a data team needs it closed today. Estates running [context layer for Databricks](https://atlan.com/know/context-layer-for-databricks/) or [context layer for Snowflake](https://atlan.com/know/context-layer-for-snowflake/) workloads alongside Fabric feel this seam directly, since neither native path is yet a finished, like-for-like substitute for what Fabric-native tooling does inside Fabric.

### Adoption and stewardship don't happen automatically

Purview ships a business glossary and governance domains, but it doesn't auto-assign data owners, auto-connect glossary terms to technical assets, or drive day-to-day steward adoption, a gap independent implementers have [written about directly](https://www.bluent.com/blog/microsoft-data-fabric-integration-for-data-governance). Configuring Purview correctly and getting a data team to keep glossary terms current are two different projects. A related failure mode, workspace sprawl, where teams spin up new Fabric workspaces faster than anyone assigns ownership, shows up in independent comparisons of [Fabric's data quality tooling](https://www.timextender.com/blog/product-technology/comparing-microsoft-fabric-data-quality-features-to-other-tools) too: treating governance as an afterthought to workspace creation is the recurring root cause.

None of these three seams argue for replacing Fabric or Purview. They argue for a layer that picks up exactly where native coverage stops, the shape of what a cross-platform context layer adds, covered next. [AI-ready data lineage](https://atlan.com/know/ai-readiness/ai-ready-data-lineage/) covers the broader pattern beyond Fabric specifically, and [Databricks Summit 2026 key takeaways](https://atlan.com/know/databricks-summit-2026-key-takeaways/) shows the same seam from the non-Microsoft side of a multi-platform estate.

---

## When do you need more than Purview and OneLake catalog?

Three signals reliably mean an estate has outgrown what OneLake catalog and Purview cover on their own: non-Microsoft platforms in the mix, AI agents that need context spanning more than Fabric, and an analyst market that already treats dedicated governance as its own category.

**Your estate includes Databricks, Snowflake, BigQuery, Redshift, or file shares Purview doesn't reach the same way it reaches Fabric.** That's the single clearest trigger, and the one both lineage and federation gaps trace back to.

**AI agents or [Copilot](https://atlan.com/microsoft-fabric-copilot/) need context spanning Fabric and non-Fabric sources.** An agent answering a business question can't stop at the Fabric boundary if the underlying data doesn't, and it needs the same [Purview controls that already secure Fabric data for AI agents](https://atlan.com/know/microsoft-fabric/purview-controls-for-ai-agents/) to extend past that boundary too. [AI agent governance](https://atlan.com/know/ai-agent-governance/), [AI security](https://atlan.com/know/ai-security/), and a genuinely [unified context layer](https://atlan.com/know/unified-context-layer/) all depend on that same context reaching every source an agent touches, not just the Microsoft-native ones, which is also [why AI agents need an enterprise context layer](https://atlan.com/know/why-ai-agents-need-an-enterprise-context-layer/) in the first place.

**The first two signals aren't situational, and the analyst market treats them as structural: dedicated data and analytics governance is already its own category, separate from the platforms it governs.** Atlan was named a Leader in [Gartner's 2026 Magic Quadrant for Data and Analytics Governance Platforms](https://atlan.com/gartner-magic-quadrant-data-governance-2026/), the same report projecting that 60% of governance teams will prioritize unstructured data governance for generative AI by 2027, with 74% already using governance tools for AI governance today. Microsoft, separately, was [named a Leader in the adjacent 2026 Magic Quadrant for Analytics and Business Intelligence Platforms](https://blog.bismart.com/en/microsoft-leader-gartner-magic-quadrant-analytics-bi-2026) for the nineteenth consecutive year. Both are true at once: strength in analytics and BI isn't the same evaluation as strength in cross-platform governance, which is why they're separate Gartner reports.

Once any of those three signals is present, the real question is whether the [context layer ROI](https://atlan.com/know/context-layer-roi/) of adding a layer clears the cost of the gaps left open, not whether Purview and OneLake catalog are good tools; they are. Teams weighing that decision against Microsoft's own [data governance tooling](https://atlan.com/know/data-governance/microsoft-data-governance-tools/) options usually find the answer depends less on what Fabric and Purview lack and more on how many non-Microsoft systems the estate already runs.

---

## What a cross-platform context layer adds to a Microsoft-first estate

A cross-platform context layer, read-only and metadata-only, with no native Purview connector today, catalogs metadata across Fabric and whatever isn't Fabric, carries lineage across the handoff between platforms instead of stopping at either one, and connects ownership and glossary terms across systems instead of leaving stewardship to happen manually. That's the shape of the gap the previous section named, narrowed to what's actually verifiable today rather than what a category description implies.

Concretely, this means: a single catalog entry for a table whether it lives in a Fabric lakehouse or a Snowflake warehouse; lineage that traces from an external source through Fabric into a semantic model and a report, and keeps tracing if the next hop is a non-Microsoft system; and glossary terms and data owners that stay attached to an asset as it moves or gets referenced across platforms, closing the adoption gap Purview leaves open on its own. Teams weighing [who owns the context layer](https://atlan.com/know/who-owns-the-context-layer/) inside their organization, and how that [ownership splits between data and AI teams](https://atlan.com/know/context-layer-ownership-data-vs-ai-teams/), tend to run into this exact stewardship question directly.

To be precise about what this is not: not a Purview replacement, not a bulk-migration tool, and not an access-control system that changes who can do what inside Fabric or Power BI. It's a layer that sits alongside Fabric and Purview, not instead of either, coexistence rather than replacement. That matters especially for regulated industries; see [context layer for financial services](https://atlan.com/know/context-layer-for-financial-services/) for how the same coexistence pattern plays out under compliance constraints. The mechanics behind it, an [enterprise data graph](https://atlan.com/know/enterprise-data-graph/) built from [context graphs](https://atlan.com/know/what-is-a-context-graph/) that AI agents can query directly, are covered in [context graphs for AI agents](https://atlan.com/know/context-graphs-for-ai-agents/), [metadata layer for AI](https://atlan.com/know/metadata-layer-for-ai/), and [data catalog for AI](https://atlan.com/know/data-catalog-for-ai/). [Context management for the CDO at enterprise scale](https://atlan.com/know/context-management-cdo-enterprise-scale/) covers the organizational side in more depth than fits here.

---

## How do you evaluate a governance layer for a Microsoft-first estate?

Evaluating a governance layer for a Fabric-heavy estate is mostly about what it does outside Microsoft, since Purview already covers the inside well. Two things matter most: exactly how deep Fabric lineage goes under which configuration, and whether the vendor is honest about what it doesn't do yet. Atlan's own documentation lays out the first trade-off more precisely than most Fabric-governance content does:

| Scanner API setting | Assets cataloged | Lineage depth | Trade-off |
|---|---|---|---|
| Enabled | Semantic models, lakehouse/warehouse tables, dataflows, notebooks (not report pages, visuals, or pipeline copy activities) | External source through semantic models to reports; table and column-level, plus Spark job lineage | Broader coverage via tenant-wide admin scanner APIs, but no lineage below the report level |
| Disabled | All of the above, plus report pages, visuals, and pipeline copy activities | Full downstream tracing from semantic model tables and columns to report pages and visuals | Requires workspace-level (Viewer role or higher) access per workspace rather than tenant-wide admin scanning; Dataflow Gen2 (CI/CD) lineage separately needs Contributor+ on its own workspaces, in either mode |

That's the detail most Fabric-governance evaluations get backwards: lineage down to individual report pages and visuals requires Scanner API Access to be **disabled**, not enabled, plus a Viewer role or higher on each workspace being crawled. Contributor+ is a separate requirement that applies only to Dataflow Gen2 (CI/CD) lineage, in both scanner modes, not to report-page or visual lineage. Get either direction wrong and the crawl silently caps out one level above what the business actually needs.

| Criterion | Why it matters | What to ask or check |
|---|---|---|
| Lineage completeness beyond Fabric | Most governance gaps show up at platform handoffs, not inside one tool | Does lineage trace into Databricks, Snowflake, or your warehouse of record, not just within Fabric? |
| Coverage of non-Microsoft systems | OneLake catalog's own federation into non-Microsoft catalogs is still in preview | Which non-Microsoft platforms does the tool catalog natively today, versus on a roadmap? |
| Security and access model | Metadata-only access limits blast radius; broader access raises it | Does the connector use Entra ID service principals, [Azure API Management managed identity](https://docs.atlan.com/apps/connectors/business-intelligence/microsoft-fabric/how-tos/set-up-microsoft-fabric-with-apim), or a self-deployed runtime that keeps credentials in your own perimeter? |
| Read-only vs. write-back | A tool that claims to fix access without writing it back is overselling itself | Does the connector modify Fabric or Power BI permissions, or only read and report on them? Fair to ask of every vendor, Atlan included; read-only is the honest, current answer here. |
| Migration path | No vendor has shipped a one-click Purview migration utility | Is migration framed as a phased, API-driven project, or a bulk export that doesn't actually exist? |
| Cost and licensing overlap with Purview | Avoids paying twice for the same coverage | Which specific capabilities does the new layer add that Purview doesn't already provide? |

A full 20-question checklist and a proof-of-value test plan that proves lineage depth before signature, rather than asserting it, both go deeper than these six criteria allow room for here. Teams building this evaluation into a broader plan tend to also read [how to implement an enterprise context layer for AI](https://atlan.com/know/how-to-implement-enterprise-context-layer-for-ai/), [what is context engineering](https://atlan.com/know/what-is-context-engineering/), [how to build an AI agent harness](https://atlan.com/know/how-to-build-ai-agent-harness/), and how a [semantic layer](https://atlan.com/know/semantic-layer/) fits underneath all three, alongside an [AI governance framework](https://atlan.com/know/ai-readiness/ai-governance-framework/) and the [context layer 101](https://atlan.com/know/ai-readiness/context-layer-101/) primer for readers newer to the term.

---

## How Atlan approaches Microsoft Fabric governance

Microsoft-first teams that standardize on Fabric and Purview eventually add Databricks, Snowflake, or an AI agent layer that needs context spanning all of it, and hit the same three gaps: lineage that stops at the Fabric/Power BI boundary, native federation into non-Microsoft catalogs that's still in preview, and adoption that doesn't happen automatically. That's the specific problem a cross-platform context layer is built to solve.

Atlan catalogs Fabric workspaces, lakehouses, warehouses, semantic models, reports, dashboards, dataflows, and data pipelines. Lineage runs from external SQL sources through Fabric into semantic models and reports in both scanner configurations, extending down to report pages and visuals specifically when Scanner API Access is disabled, with a Viewer role or higher on each workspace being crawled (Dataflow Gen2 CI/CD lineage separately needs Contributor+ on its own workspaces, in either scanner mode). The same graph extends to Databricks, Snowflake, BigQuery, and Redshift, so lineage and ownership carry across the platform handoff instead of stopping at Fabric's edge. Authentication runs through Entra ID service principals or Azure API Management with a customer-managed identity, with a Self-Deployed Runtime option keeping credentials inside the customer's own network and secret store. Every mode is metadata-only: the connector reads structural and governance metadata, never the underlying business data.

There is no shipped, generally available native Purview connector today; any coexistence with Purview runs through API-based metadata sync, never a packaged integration, and there is no one-click bulk-migration utility between the two. Treat migration as a phased, API-driven project, never a single import. The fuller picture of how Atlan and Purview coexist beyond the Fabric connector is at [Microsoft Purview and Atlan](https://atlan.com/know/data-catalog/microsoft-purview-and-atlan/).

The same catalog reaches the AI agents reading it, not just the humans: [AI agents for a data catalog](https://atlan.com/know/ai-agents-for-data-catalog/) and an [MCP-connected data catalog](https://atlan.com/know/mcp-connected-data-catalog/) both depend on [Model Context Protocol](https://atlan.com/know/what-is-model-context-protocol/) and on [MCP delivering business context](https://atlan.com/know/mcp-delivers-business-context/), not just schema, for an agent's answer to be trustworthy.

What's new: the Microsoft Fabric connector reached general availability at version 2.0, announced September 29, 2026 at FabCon Europe, bringing this same metadata-only, read-only model to OneLake and Fabric workspaces at GA.

---

## Why coexistence beats replacement for Microsoft-first governance

Fabric and Purview are genuinely strong at what they're built for. The four-pillar model, DLP, sensitivity labels, and domain-based delegation are real, well-built native capabilities, and a Microsoft-first team can run on them alone for a long time before feeling a gap. That's the accurate starting point, not a hedge.

Coverage stops at three specific, named seams, not a strawman list: the Fabric/Power BI lineage boundary, OneLake catalog's own federation into non-Microsoft catalogs like Unity Catalog that's still in preview, and adoption that Purview doesn't automate on its own. A cross-platform context layer added alongside both, not instead of either, closes those seams without duplicating what's already native. Fabric runs the workloads, Purview enforces the Microsoft-native policy, and a context layer carries what both cover well across the handoff to everything else.

For a reader whose estate has already crossed one of those seams, the practical next steps are concrete: map the Fabric-to-Power-BI lineage mechanics end to end, work through a full evaluation checklist for a Fabric governance layer, and run a proof-of-value test plan that proves lineage depth before signing anything.

---

## FAQs about Microsoft Fabric governance

### 1. What is Microsoft Fabric governance?

Microsoft Fabric governance is the set of native controls, OneLake catalog for discovery and Microsoft Purview for organization-wide policy, that manage, protect, discover, and monitor data inside a Fabric tenant.

### 2. Do you need Microsoft Purview to govern a Microsoft Fabric environment?

No. Fabric ships native governance through OneLake catalog, the Admin Portal, and workspace roles. Purview adds organization-wide DLP, sensitivity labels, and compliance scanning on top, but it is an addition, not a requirement, to get started.

### 3. What's the difference between the OneLake catalog and the Purview Unified Catalog?

OneLake catalog is scoped to Fabric items the viewer already has permission to see. Purview's Unified Catalog spans an organization's full data estate, including systems outside Fabric, with richer metadata, a business glossary, and access-request workflows.

### 4. How do you use sensitivity labels and DLP in Microsoft Fabric?

Sensitivity labels classify Fabric items by confidentiality, and Purview's Data Loss Prevention policies detect sensitive data uploaded into OneLake-supported items, then generate alerts or policy tips. Both are configured centrally in Purview and applied across Fabric workspaces.

### 5. How do you organize Microsoft Fabric workspaces across multiple domains?

Fabric groups workspaces under domains in the tenant Admin Portal, which lets domain owners set policies and delegate administration without central IT managing every workspace directly. Workspace-level roles then control who can view, edit, or administer each workspace.

### 6. Does Microsoft Purview govern Databricks, Snowflake, or file shares the same way it governs Fabric?

Not to the same depth. Purview can scan hybrid and multi-cloud sources for policy and DLP, but OneLake catalog's own federation into Unity Catalog or AWS Glue is still in preview, and coverage of unstructured sources like file shares is comparatively weak next to Fabric's native integration.

### 7. Is Atlan's Microsoft Fabric connector read-only, or can it change access permissions?

Read-only. Atlan's Fabric connector reads metadata through Fabric's APIs and cannot modify workspaces, delete assets, or change Fabric configuration. Broader Atlan governance workflows can automate access requests, which is not the same as writing access changes back to Fabric or Power BI.

### 8. Does Atlan have a native integration with Microsoft Purview?

No shipped, generally available native connector exists today. Any Atlan-Purview coexistence runs through API-based metadata sync, not a packaged native integration, and there is no one-click bulk-migration path between the two.

---

## Sources

1. [Fabric governance documentation (the four pillars), Microsoft Learn](https://learn.microsoft.com/en-us/fabric/governance/)
2. [Governance and compliance in Microsoft Fabric, Microsoft Learn](https://learn.microsoft.com/en-us/fabric/governance/governance-compliance-overview)
3. [James Serra, "The OneLake catalog in Fabric: Explore, Govern, Secure," jamesserra.com, 2026](https://www.jamesserra.com/archive/2026/04/the-onelake-catalog-in-fabric-explore-govern-secure/)
4. ["Microsoft Fabric OneLake Catalog: Features & Best Practices," Kanerika, 2026](https://kanerika.com/blogs/microsoft-fabric-onelake-catalog/)
5. ["Comparing Microsoft Fabric Data Quality Features to Other Tools," TimeXtender, 2026](https://www.timextender.com/blog/product-technology/comparing-microsoft-fabric-data-quality-features-to-other-tools)
6. ["OneLake catalog in Microsoft Fabric," Armely, 2026](https://armely.com/blog/onelake-catalog-in-microsoft-fabric-9910139260)
7. ["Microsoft Fabric Data Governance Architecture Guide," BluEnt, 2026](https://www.bluent.com/blog/microsoft-data-fabric-integration-for-data-governance)
8. [Gartner Magic Quadrant for Data and Analytics Governance Platforms 2026, recap, Atlan](https://atlan.com/gartner-magic-quadrant-data-governance-2026/)
9. [How Atlan connects to Microsoft Fabric, docs.atlan.com](https://docs.atlan.com/apps/connectors/business-intelligence/microsoft-fabric/concepts/how-atlan-connects-to-microsoft-fabric)
10. [What lineage does Atlan extract from Microsoft Fabric, docs.atlan.com](https://docs.atlan.com/apps/connectors/business-intelligence/microsoft-fabric/references/what-lineage-does-atlan-extract-from-microsoft-fabric)
11. [Set up Microsoft Fabric with Azure API Management, docs.atlan.com](https://docs.atlan.com/apps/connectors/business-intelligence/microsoft-fabric/how-tos/set-up-microsoft-fabric-with-apim)
12. ["Atlan Brings Governed Context to Microsoft Fabric and OneLake," BusinessWire via FinancialContent, 2026-09-29](https://www.financialcontent.com/article/bizwire-2026-9-29-atlan-brings-governed-context-to-microsoft-fabric-and-onelake)
13. ["Microsoft Leader in Gartner's 2026 Magic Quadrant for Analytics and BI Platforms," Bismart, 2026](https://blog.bismart.com/en/microsoft-leader-gartner-magic-quadrant-analytics-bi-2026)