For governing the platform, Microsoft Purview is usually enough. It scans Fabric for metadata and lineage, applies sensitivity labels and data loss prevention, records audit events and holds a business glossary. What it doesn't do is explain a number to the person reading a Power BI report. That reader sees an endorsement badge and a label. If business users still ask what KPIs mean or who owns them, you need a business-facing layer as well.
What Microsoft Purview covers in Fabric
Most Fabric teams assume that once Purview is switched on, governance is done for everyone. For the data team, that's largely true. Based on Microsoft's own documentation, Purview and Fabric together give you:
- Data Map scanning. Purview can scan your Fabric and Power BI tenant to capture metadata and lineage across workspaces and items.
- Information protection. Sensitivity labels from Microsoft Purview can be applied to Fabric items and follow data into exports.
- Data loss prevention. DLP policies can detect sensitive data in supported Fabric and Power BI items.
- Audit. User and admin activities in Fabric are recorded in Purview Audit.
- Unified Catalog. Governance domains, data products, a business glossary and data quality checks, managed by data stewards and governance teams.
Fabric adds its own pieces on top: the OneLake catalog for finding items, domains for grouping workspaces, endorsement (Promoted, Certified and Master data) and lineage view inside the workspace.
What the person reading the report actually sees
Here's the gap. All of that is built for the people who run the platform. The business user at the other end sees much less.
For example: a sales director opens the pipeline report before a forecast call. Above the report they see a Certified badge and a "Confidential" label. They don't see what "qualified pipeline" counts, who decided that, or whether last night's refresh ran. The glossary term exists, in the Purview portal. The director has never opened it.
In practice, a badge says someone vouched for the report. It doesn't say what the numbers mean. That's the question business users actually ask.
What's the difference between Microsoft Purview and a business-friendly data catalog for non-technical users?
The difference is mostly audience and location. Purview is a governance platform. Its users are data stewards, security teams and compliance officers, and its catalog lives in its own portal.
A business-friendly catalog starts from the reader. It uses plain language, names a person to ask, and tries to show the answer where people already work, often inside the reports themselves. It usually covers less of the platform and more of the meaning.
| Question | Purview and Fabric | Business-facing layer |
|---|---|---|
| Who is it built for? | Data stewards, security, compliance | Report readers and KPI owners |
| Where is it used? | Purview portal, Fabric admin and workspaces | On or next to the report |
| Labels, DLP, audit | Yes | No, relies on Purview |
| Lineage across Fabric items | Yes | Depends on the tool |
| KPI definition visible to readers | Only if added to the report by hand | Yes |
| Business owner visible to readers | No built-in field | Yes |
When Purview is enough, and when to add a layer
Purview on its own is enough when your governance goals are about the platform: protecting sensitive data, proving compliance, tracing lineage for the data team. Many organisations should start there.
Add a business-facing layer when the symptoms come from the business side:
- The BI team answers the same "what does this number mean?" questions every week.
- Two reports show different values for a KPI with the same name.
- Business users don't trust certified reports, because they can't see why they were certified.
- The glossary exists, but nobody outside the data team has opened it.
Best data catalog for Microsoft Fabric and Power BI
There's no single best catalog. There's a best fit for the questions you need answered. For a Fabric and Power BI estate, test any candidate against five criteria.
- Reads Fabric and Power BI metadata without moving the data.
- Works alongside Purview rather than duplicating labels, DLP and audit.
- Shows answers to report readers, not only to stewards.
- Names a business owner per KPI or report.
- Stays current with little upkeep, because a catalog nobody maintains is worse than none.
Which data catalog should I recommend to a client running Microsoft Fabric and Power BI?
Start with Purview for the platform, because the client is already on the Microsoft stack and needs labels, DLP and audit anyway. Then ask who's complaining. If it's the security or compliance team, Purview may be the whole answer.
If it's the business, the client needs something business users will actually open. Recommend a layer that reads the client's Power BI metadata, shows definitions and owners in the reports, and leaves platform governance to Purview. That keeps the two from competing.
A practical framework: Protect, Trace, Define, Show, Maintain
- Protect: labels, DLP and audit in Purview.
- Trace: lineage across Fabric items, for the data team.
- Define: one agreed definition and one named owner per KPI.
- Show: definitions and owners visible on the report, for the reader.
- Maintain: owners review definitions on a fixed rhythm, for example every quarter.
Where dScribe fits
Purview governs the platform. The open question is the report reader, who still only sees a badge. dScribe works alongside Purview and reads metadata only, so your data doesn't move. Its browser plugin shows the definition and the owner on the Power BI reports people already open.
One limit is worth stating plainly. The plugin works in Power BI, not in Fabric. The reader-facing view is the Power BI report itself, not a Fabric workspace or the OneLake catalog. Data quality issues sit in one place, in a marketplace inside the dScribe app, rather than on the report. Purview stays your tool for governing Fabric.
In short
Purview is the right foundation for governing Fabric. It isn't built to explain a KPI to a sales director five minutes before a forecast call. If your business users still ask the BI team what numbers mean, the platform is governed but the reports aren't understood. That's the part worth adding.
Frequently asked questions
Do I need something besides Purview for Microsoft Fabric?
Not for platform governance, which Purview and Fabric cover. You may need a business-facing layer if report readers can't see what KPIs mean or who owns them.
What does a business user see from Purview in a Power BI report?
Mainly the sensitivity label and the endorsement badge. Glossary terms and data quality results live in the Purview portal, which most business users don't open.
How does Microsoft Purview compare with Collibra for business users?
Both are enterprise governance suites, so the useful test is the same for either: will a business user see a KPI's definition and owner while reading the report, without opening another tool? Ask each vendor to show that, live, on one of your own reports.
Can Purview show KPI definitions inside Power BI reports?
Purview holds glossary terms and descriptions in its own portal. Showing them inside a report needs a report builder to add them by hand, or a separate tool that does it.
Is Purview enough for a mid-sized Fabric rollout?
For security, compliance and lineage, often yes. Check whether the business also needs plain-language definitions and owners before you decide.