Evaluating a Governance Platform for Fabric: 20 Questions to Ask

---

Evaluating a governance platform for a Microsoft Fabric estate means testing six things, not reading a feature list: lineage depth, coverage beyond Microsoft, the access model, whether governance workflows actually change anything, the migration path, and cost. Fabric and Purview handle native Microsoft policy well, and the gaps buyers report show up at the seams: where lineage crosses from Fabric into Snowflake or Databricks, or where an approval never touches a real permission. Twenty specific, demonstration-ready questions across those six groups, plus a weighted scorecard, turn a vendor’s answer into something you can score rather than just remember.

---

A few things worth knowing before you run these questions against any vendor:

• Every question here applies to every vendor you evaluate, including Atlan. This is not a disguised sales pitch. Where a capability isn’t verified, including for Atlan’s own connectors, that’s stated plainly rather than glossed over.
• “Supported” and “usable” are different claims. A connector can scan a system without producing lineage, permissions, or workflows a business user can actually rely on.
• The six groups, if you want to jump straight to one: lineage completeness and depth, coverage beyond the Microsoft estate, the security and access model, governance workflows that actually change something, migration and coexistence with Purview, and cost, licensing, and vendor viability.
• A scorecard near the end turns all 20 answers into a single weighted number you can defend to a buying committee, instead of 20 disconnected impressions.

Evaluation at a glance

---

Why does Purview alone leave gaps in a Fabric-first estate?

Microsoft Purview enforces Microsoft-native policy well, and most of what buyers report struggling with happens exactly where “Microsoft-native” stops. The inaugural Gartner Magic Quadrant for Data and Analytics Governance Platforms, published in January 2025, is itself evidence that this category only just consolidated into a named market. Microsoft’s own governance documentation draws a clear line between what’s native to Fabric (the Admin Portal, the OneLake catalog, domains) and what Purview adds on top (Information Protection, DLP, sensitivity labels, audit).

The pattern buyers describe is not that Purview fails at its job. It’s that lineage stops before it reaches a warehouse outside Microsoft, a catalog only really works for Microsoft technologies, or a governance workflow doesn’t change a real permission once you look closely. Three independent sources converge on the same shape of gap: practitioners on Reddit, a market-intelligence scan tracking competitor moves in this exact space, and McKinsey’s research on AI data readiness, which frames a governed, traceable, reusable data foundation as the actual constraint on scaling AI, not the presence of any single governance tool. None of that is an argument against Purview. It’s the argument for testing what happens at the boundary before you assume the boundary doesn’t matter.

That boundary isn’t universal, and it’s worth taking seriously rather than skimming past. One honest counterpoint from a genuinely Azure-native practitioner on r/AZURE put it plainly: if your estate runs entirely inside Azure, you’re “pretty much bound to Purview” anyway. For an estate that genuinely fits that description, that isn’t a consolation prize. It’s the correct, lower-cost answer, and the questions below will confirm it rather than talk you out of it.

Choose Purview alone if: your estate is genuinely Azure-native end to end, and you don’t run Databricks, Snowflake, BigQuery, or other non-Microsoft systems in production.

Look beyond Purview if: any material part of your estate, a warehouse, a lakehouse engine, a BI tool, a shared drive, sits outside Fabric and Azure, or governance approvals inside your tools today don’t change a real permission.

Run the six groups below against any vendor on your shortlist, Atlan included, and score the results with the scorecard toward the end. For the fuller picture of what’s native to Fabric versus what a Microsoft-first estate typically still needs to add, see Microsoft Fabric governance: what’s built in and what you add.

---

What questions test lineage completeness and depth in Fabric?

Lineage is the hardest capability to verify from a vendor’s feature list, because “supported connector” and “usable lineage” are not the same claim. A vendor can scan a system and still fail to show you the column-level transformation, the report-to-source trace, or the permission that gated it.

1. Can the vendor demonstrate column-level lineage live, tracing from an external source (Snowflake, Synapse, SQL Server) through a Fabric lakehouse or warehouse table, into a semantic model, and onto a specific Power BI report and visual, rather than describing it on a slide?
2. Does reaching report-page and visual-level lineage require Fabric’s Scanner API to be on or off, and what workspace-level permission does that require from your security team? State this precisely for every vendor you ask, and don’t let the answer blur two different depths. General report-page and visual lineage needs Scanner API disabled plus Viewer access on the crawled workspace, which is how Atlan’s own Fabric connector works. The deeper depth Q1 tests, column- or measure-level lineage traced onto a specific page, is a separate mechanism read from each report’s definition, and it needs Contributor or higher instead; a Viewer role produces nothing there, because Microsoft’s own report-definition API requires write permission on the report. With Scanner API enabled, neither depth is reachable at all.
3. Is lineage genuinely bidirectional? Can a business user start at a report visual and trace back to the source table, and can an engineer start at a source table and see every downstream report it feeds?
4. What happens to lineage completeness if your team crawls Power BI through the Fabric connector instead of the dedicated Power BI semantic model connector, or vice versa? Does the vendor proactively warn you about that choice, or leave you to discover it later?

A practitioner thread on r/MicrosoftFabric described the standard Fabric lineage view as showing semantic models tied to an entire warehouse rather than the specific table feeding it, a granularity gap that’s easy to miss in a demo and hard to live with in production. A separate r/MicrosoftFabric thread reported that Power BI lineage sometimes required manual API integration rather than automatic detection. Ask a vendor to close that exact gap live, not describe it.

Testing lineage by asset type

Documenting the exact prerequisite for that depth matters more than the marketing claim itself. Atlan’s own Fabric setup and crawl documentation states the Scanner API and permission requirement in writing, which is exactly what Q2 above asks every vendor to produce. A guide that can’t show its prerequisite in writing is asking you to take the depth claim on faith. Don’t.

---

What questions test coverage beyond the Microsoft estate?

Purview is strong inside Microsoft and untested at the boundary. The questions below check what happens the moment your estate includes anything Purview doesn’t reach.

5. Can the tool catalog and lineage-trace Unity Catalog, Snowflake, BigQuery, Redshift, or other non-Microsoft systems in the same graph as Fabric, not as a second, separate catalog you maintain in parallel?
6. How does the tool handle shared drives and other unstructured storage that sits outside Fabric and Azure entirely?
7. If your estate already splits governance between Unity Catalog for Databricks and Purview for everything else, can this tool stitch one coherent lineage and policy view across both, or does it just add a third control plane?

A Databricks-heavy practitioner on r/databricks expected Purview to serve as a Unity Catalog lineage front end and instead found its Unity Catalog extraction limited in a complex environment, close enough to a third-party catalog’s role that it read more like Atlan or Collibra than like Unity Catalog’s own tooling. A separate r/dataengineering thread recommended running a focused proof of concept specifically because Purview’s non-Azure-estate limitations don’t show up until you test them directly. Neither of these is a knock on Purview; it’s evidence that “coverage beyond Microsoft” is a real, separately-testable question, not an assumption to skip.

A tool that genuinely unifies Fabric with a cross-cloud governance platform has to answer the same “is the hyperscaler-native tool enough on its own” question every hyperscaler-adjacent estate eventually asks, whether the native tool in question is Purview, AWS DataZone, or Databricks’ own Unity Catalog. If a vendor’s answer to Q7 is a second dashboard rather than one graph, that’s the tell to press on before you sign, not after.

---

What questions test the security and access model?

A governance tool that needs broad, standing credentials to every system it touches is itself a new security surface, so this group tests how narrowly the vendor can scope access.

8. Does the tool authenticate via an Entra ID service principal, or can it run through Azure API Management with a managed identity, so a service-principal secret is never exposed to it directly?
9. Is there a self-deployed or agent-based runtime option that keeps metadata extraction and credentials inside your own network perimeter?
10. Does the tool read only metadata, or does it also touch the underlying business data, and can you verify that boundary in the vendor’s own documentation, not just a sales conversation? Atlan’s own connector authentication reference states plainly that its Power BI connector “is read-only,” which is the kind of written, checkable answer this question is designed to surface, not a verbal assurance.

Every one of these questions has a forward-looking version too, since a Fabric estate’s governance tool increasingly has to answer for AI agents, not just human users. Purview’s own AI agent controls and a companion set of Fabric AI agent governance questions go deeper on that specific angle than fits here. So does the broader question of what a documented AI governance framework needs to cover once agents, not just dashboards, are reading the context this security model protects.

Purview and Fabric handle native Microsoft policy well, and the honest answer to most of these three questions, for Purview, is that it was built inside Microsoft’s own security model from the start. The reason to ask them of every other vendor too is that a third-party layer inherits none of that by default; it has to earn the same answer independently.

---

Which governance-workflow questions actually change something?

A workflow that looks like governance in a vendor demo and a workflow that changes a real permission are different claims, and this is the group where that gap shows up most.

11. When someone approves an access request inside this tool, does that approval change a real permission in Fabric, Power BI, or Entra ID, or does it only send a notification? Ask for a live demonstration of an approval that actually alters access, for every vendor you evaluate, including the incumbent.

12. Can a business user, not just a data engineer, search for an asset, understand what it means, and request access to it without being dropped into a purely technical interface?
13. Can a policy, a sensitivity classification, an ownership assignment, a certification, be applied consistently to a data asset and to any AI agent output derived from it, or are those two different, disconnected policy surfaces? McKinsey’s playbook on deploying agentic AI safely argues that agents need to be treated as principals subject to policy in their own right, not as a side effect of the human policy already in place, which is exactly what this question is testing for.
14. Does the tool support Fabric’s domain and sub-domain ownership model, or does everything collapse into one flat, ungoverned namespace regardless of how your organization is structured? A tool that can’t see who governs agent-created Fabric items in the first place has no domain model to enforce at all.

A recurring practitioner theme, not a sourced quote, is that Purview approvals can create false confidence: approved inside the tool’s own UI, with the underlying Fabric or Entra permission left unchanged until someone follows up manually. Treat that as a reason to demand Q11’s live demonstration from every vendor, not as a claim about any one product’s defect.

---

What questions cover migration and coexistence with Purview?

No governance tool replaces Purview in a Microsoft-first estate overnight. What separates an honest vendor here is whether they’re upfront about what coexistence actually takes.

15. Is there a documented, phased way to sync glossary terms, classifications, and lineage from Purview via open APIs, and does the vendor say plainly that this is a multi-step project, not a one-click migration? No vendor in this research, Atlan included, has a documented one-click Purview migration utility as of this writing.
16. If you’re moving workloads from Synapse or another platform into Fabric, can the tool carry forward existing metadata, definitions, and lineage, so your team isn’t rebuilding documentation from a blank page?
17. If a vendor claims a “native Purview connector,” ask exactly what that means technically. Is it a genuinely native integration, or an API-based sync described with more confident marketing language than the underlying mechanism deserves? This applies to Atlan’s own language too: describe Atlan’s Purview integration as open-API synchronization of glossary terms, classifications, and lineage, not a native connector, per Atlan’s own Microsoft Fabric integration documentation.

Coexistence, done honestly, is a phased overlay: connect a read-side context and lineage layer across Fabric, Power BI, warehouses, and whatever Purview APIs are available, reconcile the glossary and classification metadata, then decide over time which responsibilities stay in Purview and which move. A vendor who skips straight to “we replace Purview” in an evaluation conversation is worth a second look, since that framing contradicts what every account in this research actually did. It also skips past the enterprise context layer work of reconciling two systems’ definitions of the same asset, which is where most of the real migration effort lives.

---

What questions determine cost, licensing, and vendor viability?

The license line item is rarely where a Fabric governance tool’s real cost shows up. It’s in the engineering hours spent stitching what the license didn’t cover.

18. What’s actually included in the Fabric and Power BI-bundled tier of Purview, and which capabilities require a higher licensing tier or a separate tool entirely?
19. What does total cost of ownership look like once you count the engineering time spent on manual lineage stitching, custom scripts, and fixing connector misconfigurations, not just the license line item? Published vendor-neutral criteria for choosing a governance tool name total cost of ownership as one of seven evaluation dimensions, alongside scalability, integration, usability, policy granularity, AI governance readiness, and vendor support, worth asking about directly rather than inferring from a price sheet.
20. Is the vendor independently validated for this specific capability set, a named analyst framework, a documented production customer base at your scale, or is the evidence mostly the vendor’s own claims about itself? The Forrester Wave for Enterprise Data Catalogs, Q3 2024, which scored 12 vendors across 24 criteria, and the Forrester Wave for Data Governance Solutions, Q3 2025, which scored 13 vendors across 28 criteria, are both examples of what “independently validated” actually looks like: a defined, public methodology you can check a vendor’s specific claim against, rather than take on faith.

One independent, practitioner-run source worth checking directly rather than trusting a vendor’s restatement of it: The Data Governor’s 2026 scoring matrix weights six criteria, governance depth and policy enforcement, catalog and lineage coverage, steward and business adoption, cost transparency, interoperability, and analyst validation, and scores Purview and several third-party platforms within a few points of each other. Read a margin that close as evidence the category is genuinely competitive, not as a verdict.

---

How do you score vendors across these 20 questions?

Twenty questions produce twenty answers, not a decision. Run honestly, the pattern that tends to emerge is that Purview scores well on the groups closest to native Microsoft policy, security and access, and migration and coexistence, while the real separation shows up in coverage beyond Microsoft and governance workflows that change something. That’s not a rule; it’s the direction the practitioner threads and analyst frameworks cited throughout point toward, and it’s exactly what a cross-platform layer has to earn, not assume. A single weighted score, built from your own 20 answers, is what you can actually defend to a buying committee.

Weighted evaluation scorecard

Scoring guide: 5 means live-demonstrated with no caveats, 3 means it works with a documented workaround, 1 means the vendor could not demonstrate it live at all.

Red flags worth ending a conversation over: the vendor can’t run the demo against your own data; a claimed capability is “on the roadmap” rather than shipped; an approval demo shows a notification, not a permission change; a “native Purview connector” claim isn’t backed by a technical explanation when you ask Q17; there’s no reference customer at your scale or in your industry.

A practitioner thread on r/dataengineering called lineage the single most important thing to test before committing to a tool, and a separate r/analytics thread found one enterprise catalog “quite lacking” specifically because the setup looked simple until an actual heterogeneous estate hit it. Score the scorecard using your own estate, not the vendor’s demo environment, and the same lesson holds. The scorecard is most useful as a shared artifact across the group named earlier, the governance lead, the architect, data leadership, and security, rather than one person’s private notes.

Running this scorecard once, in a meeting, is a start. Running it against a live proof of value, with your own data and your own failure cases, is what actually separates a vendor’s claim from a vendor’s capability; see proving Fabric and Power BI lineage in a proof of value for the test plan that operationalizes exactly that step.

---

How Atlan approaches Fabric governance

Every one of the 20 questions above exists because a Microsoft-first estate eventually includes something Purview doesn’t reach, or needs a governance workflow to do more than notify. That’s a coexistence gap, not a shortcoming in Purview.

Atlan’s Fabric connector catalogs workspaces, lakehouses, warehouses, semantic models, reports, dashboards, and dataflows, with lineage running from external sources through Fabric into semantic models and reports. Report-page and visual-level depth needs Scanner API disabled plus Viewer access on the crawled workspace; the deeper column- and measure-to-page lineage Q1 tests needs Contributor or higher instead, per Q2. Authentication runs through Entra ID service principals or Azure API Management with a managed identity. A self-deployed runtime option keeps extraction and credentials inside the customer’s own perimeter. Purview coexistence runs through open-API synchronization of glossary terms, classifications, and lineage, described honestly as API-based sync, per Q17, not a native connector. That is what “the context layer for AI” means in a Fabric estate specifically: one coherent graph across Fabric, Purview, and whatever sits outside both, built for the enterprise context layer an AI agent needs as much as a human analyst does. None of the capabilities above are exempt from the standard every question above sets: verify each one live, against your own estate, the same way you’d verify any other vendor’s claim.

On the independent-validation question Q20 raises for every vendor, The Data Governor’s 2026 scoring matrix put Atlan at 76 out of 100 against Purview’s 75. That margin is close enough to read as “both are credible, evaluate for your own estate,” not a decisive win. Two segment-level illustrations from this research, never named accounts, show what that looks like in practice: a public-sector account running PHI classification across Fabric and beyond it, and a financial-services account testing end-to-end lineage from an external database into a Power BI report before committing. Two examples are a pattern worth naming, not a statistic; treat them as illustrative, not as proof of frequency.

See how Atlan scores against your own version of this scorecard, using your own estate, not a demo environment.

Twenty questions, grouped into six categories, turn a vendor evaluation from a feature-list comparison into a defensible, scored decision, provided every answer comes from a live demonstration against your own data, not a slide. The pattern across independent practitioner threads and this research is consistent: Purview and Fabric handle native Microsoft policy well, and the real gaps sit at the seams, a platform boundary, a connector choice, an approval that never reaches a real permission. RBAC write-back stays an open question for every vendor, Atlan included, until someone demonstrates it live. A third-party layer is not always the answer; a genuinely Azure-native estate may not need one. Run the scorecard against a proof of value before you sign anything: proving Fabric and Power BI lineage in a proof of value is the next concrete step for a reader ready to test rather than just ask.

For the mechanics behind Group 1 specifically, see end-to-end column-level lineage for Power BI. Related reading beyond Fabric: what is context engineering, how to implement an enterprise context layer for AI, what is a context graph, semantic layer vs. data catalog, context layer vs. semantic layer, Unity Catalog vs. a cross-platform semantic layer, AI readiness platform evaluation, AI readiness assessment, AI-ready data, AI model governance, AI risk management, what are Microsoft Copilot Studio agents, Fabric IQ vs. Work IQ vs. Foundry IQ, and how to build an AI agent harness.

Outside the context-page pool but useful for a Fabric-first reader: Power BI data governance, a Power BI data catalog setup guide, and Purview vs. Databricks Unity Catalog.

---

FAQs about evaluating a Fabric governance platform

1. How long does a Fabric governance platform evaluation typically take?

Budget 8-12 weeks from initial research through vendor demos, plus a separate 2-4 week proof of concept before a final decision. Skipping the proof of concept is the most common regret practitioners report after signing.

2. Who should be involved in evaluating a governance platform for a Microsoft Fabric estate?

The data governance lead, an enterprise architect, data and analytics leadership, and someone from security or IT who can speak to the access model. Score it as a shared scorecard across that group, not one person’s private checklist.

3. How do you run a proof of concept for Fabric governance before signing a contract?

Scope it to 2-3 real use cases using your own data, require a live demonstration of the source-to-visual lineage chain and an access approval that actually changes a permission, and define pass and fail criteria before the proof of concept starts, not after.

4. What’s the single most important criterion when evaluating a governance platform for Fabric?

Lineage, by practitioner consensus across independent Reddit threads on Microsoft Fabric, data engineering, and Databricks communities. Test it at the asset-type level, not the platform level, since a single “supported” claim at the platform level can hide real gaps underneath.

5. What’s the difference between Microsoft Purview and Microsoft Fabric’s built-in governance?

Fabric’s own Admin Portal, OneLake catalog, and domains are native and included. Purview’s Information Protection, data loss prevention, sensitivity labels, and audit features are a separate, deeper layer that Microsoft’s own documentation distinguishes clearly from what ships natively in Fabric.

6. Can a third-party governance platform coexist with Microsoft Purview, or does it replace it?

Coexist, in every account this research found. Fabric runs the workloads, Purview enforces Microsoft-native policy, and a cross-platform layer picks up where Purview’s Microsoft-only scope ends. Purview replacement is never the assumption here.

7. Is Microsoft Purview enough on its own for a Fabric-first estate?

Sometimes, honestly. If your estate is genuinely Azure-native end to end, with nothing outside Fabric and Azure, Purview alone may cover it. Running the 20 questions above is how you find that out for certain instead of guessing.

---

Sources

1. Governance and Compliance in Microsoft Fabric, Microsoft Learn
2. Solidatus Named in Inaugural 2025 Gartner Magic Quadrant for Data and Analytics Governance Platforms, Solidatus
3. Recommended Data Governance Solution for Smaller Azure Estates, r/AZURE
4. AI Data Readiness: The Key to Scaling Impact, McKinsey
5. Lineage for Table, r/MicrosoftFabric
6. End-User Facing Data Catalog With Fabric, r/MicrosoftFabric
7. Set Up Microsoft Fabric, Atlan Documentation
8. Crawl Microsoft Fabric, Atlan Documentation
9. We Expected Purview to Be Our Databricks Data Governance Front End, r/databricks
10. Purview Or…?, r/dataengineering
11. Connector Authentication and Setup Reference, Atlan Documentation
12. Deploying Agentic AI With Safety and Security: A Playbook for Technology Leaders, McKinsey
13. Microsoft Fabric Integration FAQ, Atlan Documentation
14. The Forrester Wave: Enterprise Data Catalogs, Q3 2024, Forrester Research
15. The Forrester Wave: Data Governance Solutions, Q3 2025, Forrester Research
16. Data Governance Tools, r/analytics
17. Using Microsoft Purview as Enterprise-Wide Data Catalog, r/dataengineering
18. Data Governance Platforms Ranked: 2026 Scoring Matrix, The Data Governor