What Is Microsoft Purview? A Practitioner's Guide

Microsoft Purview is Microsoft’s unified data governance platform that catalogs, classifies, and tracks data assets across Azure, Microsoft 365, and on-premises environments—enabling compliance, lineage visibility, and policy enforcement without requiring separate tools.

Introduction

I’ve spent the last several years helping enterprise teams navigate the vendor landscape for data governance, and one question I hear constantly is: “Where does Microsoft Purview fit?” It’s a fair question. Microsoft has bundled governance capabilities into what they call a unified platform, and the pitch sounds compelling—one tool across your cloud infrastructure, Microsoft 365, and on-premises systems. But “unified” is one of those words that means different things depending on who’s selling it and who’s buying it.

Here’s what I’ve learned: Microsoft Purview is genuinely useful for teams already deep in the Microsoft ecosystem, but it’s not positioned the same way as traditional data governance platforms like Collibra or Alation. It’s more of a distributed governance engine that lives closest to your data sources and Microsoft services, rather than a central metadata repository that teams gather around for collaboration and stewardship.

This guide is for practitioners who need to understand what Purview actually does, where it excels, where it falls short, and most importantly—how to decide whether it fits your governance program or whether you need to combine it with other tools. I’ll walk through the architecture, the main features, pricing, and the real trade-offs I’ve observed in the field. By the end, you’ll know whether Purview deserves a place in your governance stack or whether you’re better off with a dedicated platform.

What Microsoft Purview Is and Who It Is For

Purview data governance started as Azure Purview—a metadata discovery and lineage tool launched in 2020—and has evolved into a broader suite that includes compliance and data loss prevention (DLP) capabilities. The rebranding to “Microsoft Purview” reflects Microsoft’s ambition to position it as a unified solution across Azure, Microsoft 365, and hybrid environments.

At its core, Purview does four things: it catalogs your data assets, classifies data automatically, tracks lineage and relationships, and enforces policies. None of these functions is new to the market, but the value proposition is that they all live within Microsoft’s ecosystem—accessible from Azure Portal, integrated with Microsoft 365 services, and connected to Microsoft’s identity and compliance infrastructure.

The target customer is an organization that is already committed to Azure and Microsoft 365, has data spread across those services, and wants governance without a separate vendor relationship. If you’re running Azure Synapse, Azure Data Lake, Fabric, SharePoint, Teams, or Exchange—and you’re spending budget with Microsoft already—Purview makes operational sense. You don’t need to authenticate to another system, you don’t need to learn another UI, and your classifications feed directly into DLP policies in Microsoft 365.

But there’s a catch: Purview is not a collaborative governance platform in the way that Collibra or Alation are. It’s a plumbing tool. You use it to map your data landscape, apply labels, and enforce rules. But if your program depends on stewards collaborating, defining shared glossaries across business and IT, or running a formal data quality accountability structure, Purview alone won’t get you there. You’ll either need to bolt on additional tools or accept a governance model that’s more technical than strategic.

The Purview Data Map and Unified Catalog

The Purview data catalog is the visual and metadata foundation of the platform. When you scan a data source—an Azure SQL Database, an on-premises SQL Server, a Snowflake warehouse, a SharePoint site—Purview catalogs the assets, extracts metadata, and makes them searchable.

The Purview Data Map is the graph database that holds everything: tables, columns, files, dashboards, lineage relationships, and classifications. You query it through a search interface that feels familiar if you’ve used Azure Cognitive Search. The catalog is not a replacement for your business glossary or business metadata layer—it’s a technical asset inventory with cross-source lineage visibility.

In practice, I’ve found the catalog works well for discovery at scale. If you have a data engineer who needs to find all tables containing a PII field, or all datasets that feed a particular dashboard, Purview’s search and filtering gets you there faster than manual documentation. The lineage graph shows you which Azure Data Factory pipelines transform data and which Power BI reports consume it.

The catch: the Purview data catalog is read-heavy. You push data in through automated scans, but you’re not typically collaborating within Purview to build shared business glossaries or publish curated assets the way you would in Collibra. If you want a business-facing catalog where stewards can annotate assets, define business terms, and attach documentation, you’ll need to integrate Purview with another tool or accept a more technical catalog experience.

Integration matters here. Purview can export metadata to other systems, and some platforms can consume Purview’s catalog as a source of technical truth, but that’s typically an engineering integration, not a seamless user experience. This is where the “unified” claim starts to fracture—Purview is unified within the Microsoft stack, but it doesn’t natively unify your business and technical governance layers.

Lineage, Classification, and Sensitivity Labels

Purview data lineage tracking is one of the platform’s genuine strengths, especially for Azure-native workloads. When you run an Azure Data Factory pipeline that reads from a data lake, transforms it with Synapse, and lands it in a warehouse, Purview can automatically trace that lineage without you writing a custom integration. The lineage graph shows you end-to-end—from source system to BI layer.

This is valuable. Lineage is one of the hardest governance problems to solve at scale, and Purview handles it better for cloud-native architectures than most competing platforms. If your data flow is entirely Azure Data Factory → Azure Data Lake → Azure Synapse → Power BI, Purview gives you visibility with minimal manual configuration.

Classification in Purview comes in two flavors: system-defined and custom. Out of the box, Purview can scan for PII patterns—email addresses, phone numbers, social security numbers, credit card formats. You can also define custom classification rules using regex or keyword patterns. When a classification is applied, it sticks to the asset in the Purview catalog.

The real power emerges when you connect classification to Microsoft Purview compliance and DLP. If you classify a column as “Credit Card Number,” you can automatically label it in Microsoft 365 with a sensitivity label like “Confidential.” That label then enforces DLP policies—preventing the file from being shared externally, or requiring encryption. This integration is genuinely seamless because it’s all within Microsoft’s infrastructure.

But here’s what I’ve seen trip up teams: classification quality matters enormously, and Purview’s built-in classifiers are pattern-based, not semantic. They’re good at finding email addresses or phone numbers, but they can miss context-dependent sensitivity. A column called “customer_address” might hold sensitive location data, but Purview won’t flag it unless you define a custom classifier. That means you still need humans in the loop to audit and refine classifications—Purview accelerates the work, but it doesn’t eliminate the governance effort.

Purview for Compliance and DLP

The purview compliance portfolio includes data loss prevention, insider risk management, and e-discovery capabilities that are more traditional Microsoft 365 security features integrated into the Purview brand. When people talk about “Microsoft Purview for compliance,” they usually mean DLP: policies that prevent sensitive data from leaving your organization via email, file sharing, or copying to unauthorized cloud apps.

Where this gets powerful is the integration with data classification. You classify a dataset as “Credit Card Data” in the Purview data catalog. That classification flows to Microsoft 365 labels. You then create a DLP policy that says: “If a file has the ‘Credit Card Data’ label, prevent external sharing and require encryption.” The policy runs automatically against files in SharePoint, Teams, and OneDrive. No manual intervention needed.

For organizations running a tightly integrated Microsoft 365 and Azure environment, this workflow is elegant. You define governance once, in the Purview data catalog, and compliance enforcement cascades through the entire Microsoft stack.

The limitation: DLP policies in Purview are reactive. They enforce rules on data that’s already classified. If your data isn’t in the Purview catalog or hasn’t been classified, DLP policies don’t see it. And Purview’s DLP is primarily concerned with preventing exfiltration—it’s not a purpose-limitation engine. It can’t easily enforce “this data may only be used for customer service purposes” or “this dataset may only be accessed by the finance team.” Those more nuanced governance policies require a dedicated platform.

Additionally, if you’re using non-Microsoft cloud services—Salesforce, Snowflake, Databricks, Tableau—Purview’s compliance layer doesn’t extend into those systems. You can catalog them and see lineage, but you can’t enforce DLP policies across them. That’s a hard boundary for many enterprises operating in multi-cloud environments.

Architecture and Deployment Models

Purview has evolved through a few deployment models, and it’s worth understanding the current state. Originally, Azure Purview was a dedicated Azure service that you provisioned and operated. Starting in 2023, Microsoft began consolidating Purview capabilities into Fabric and expanding the portal experience.

As of 2026, the primary way teams interact with Purview is through the Purview Portal (portal.purview.microsoft.com), which provides a unified interface for data catalog, classification, lineage, and compliance features. Behind the scenes, Purview still runs on Azure infrastructure—you don’t provision a “Purview instance” the way you do a Data Factory or Synapse workspace. Costs are consumption-based.

For teams running Fabric (Microsoft’s unified analytics platform), Purview integration is baked in. When you create a lakehouse, warehouse, or semantic model in Fabric, it automatically appears in the Purview catalog. Lineage is automatically captured. This is genuinely convenient if you’re using Fabric as your primary analytics platform.

For on-premises and non-Microsoft sources, Purview uses a self-hosted integration runtime to scan assets. You install a lightweight connector in your environment, point it at your SQL Server, Snowflake, Databricks, or other source, and Purview catalogs the schema and metadata. The experience is smooth, but you’re still responsible for managing the integration runtime and network connectivity.

I’ve found that Purview’s deployment complexity is lower than traditional data governance platforms for pure Azure environments, but it increases significantly if you have hybrid or multi-cloud data sources. You’re essentially running a separate governance tool for each major data silo—Purview for Azure and Microsoft 365, maybe Collibra or Alation for enterprise data lakes, Snowflake’s native governance features for Snowflake-specific assets.

Microsoft Purview Pricing and Total Cost of Ownership

Microsoft Purview pricing is consumption-based, not seat-based, which is different from traditional data governance vendors. You pay for data scanned, assets cataloged, classifications applied, and DLP policy evaluations. As of 2026, Microsoft’s pricing model includes tiers for each capability.

Here’s the rough structure: you pay per gigabyte scanned by the data map, and you pay separately for compliance features. A typical enterprise scanning 100 GB of data across Azure and Microsoft 365 might spend $500–$2,000 per month on Purview, depending on scan frequency and classification volume. That’s significantly cheaper than Collibra or Alation licensing, which often start at $100,000+ annually for comparable organizations.

The catch is that simplistic pricing comparison misses the real cost equation. If Purview alone doesn’t give you the collaborative governance layer or the business glossary management that your program needs, you’ll layer on another tool anyway. At that point, you’re paying for Purview plus Collibra or Alation, which is expensive.

Additionally, Purview pricing can creep upward quickly if you’re scanning frequently or applying many classifications. If you have 50+ data sources and you’re running daily scans across all of them, your consumption-based bill can approach or exceed a traditional seat-based model. I’ve seen organizations underestimate this and face sticker shock after the first quarter.

For a pure cost comparison, treat Purview pricing as: “lower entry cost, high transparency, variable based on usage.” Compare it to Collibra’s licensing only if your use case is tightly scoped to Azure and Microsoft 365. If you’re building an enterprise governance program, account for the fact that you may need additional tools.

Where Purview Fits in a Governance Program

In my experience, Purview works best as a specialized component of a larger governance program, not as a standalone platform. Here’s the mental model I use: unified data governance platforms like Collibra are orchestrators—they pull metadata from multiple sources, centralize it, and provide a collaboration layer where business and technical teams align on definitions, ownership, and policies. Purview is an amplifier—it accelerates governance execution within the Microsoft ecosystem.

If your organization is primarily Azure and Microsoft 365, with minimal investment in non-Microsoft data platforms, Purview can be your primary governance tool. You use it to catalog everything, classify data, define ownership, and enforce DLP policies. Your teams learn one interface and one governance model. This is the strongest use case for Purview.

But if you’re like most large enterprises—with data scattered across Azure, on-premises systems, Snowflake, Databricks, Salesforce, Tableau, and other platforms—Purview becomes one tool among many. In this scenario, I recommend thinking of Purview as your Azure governance engine. It handles cataloging and compliance for Azure and Microsoft 365 assets. Your business glossary and cross-platform governance orchestration lives in Collibra or Alation. Those platforms consume Purview’s metadata through APIs, so you maintain a single source of truth for asset relationships, but you collaborate in a true unified governance platform.

This hybrid approach is more complex operationally—you’re integrating multiple tools—but it avoids forcing non-Microsoft teams and data sources into a platform designed primarily for Microsoft’s stack. I’ve also found that teams starting with Purview and planning to expand later often wish they’d chosen a true cross-platform governor from the beginning, because retrofitting a unified platform later is harder than building the right architecture initially.

Strengths, Limits, and When to Look Elsewhere

Let me be direct about Purview’s strengths, because they’re real. First, for Azure-native organizations, Purview’s integration with Azure services is unmatched. Lineage is automatic, classifications propagate to DLP policies seamlessly, and you’re not context-switching between tools. Second, Purview is cost-effective compared to traditional vendors—you’re not paying per-user licensing for hundreds of seats. Third, the DLP enforcement in Microsoft 365 is genuinely strong; if preventing exfiltration of sensitive files is your primary governance concern, Purview delivers.

The limits are equally clear. Purview is not a collaborative governance platform—it’s missing the stewardship workflows, glossary management, and cross-functional alignment tools that Collibra or Alation provide. It’s not purpose-limitation or usage-based access control—you can’t easily enforce “this data is only for marketing” or “only senior analysts can access this.” It doesn’t extend governance into non-Microsoft platforms—if you use Snowflake, Databricks, or Tableau, you’re not enforcing Purview policies there. And its business glossary and metadata enrichment capabilities are minimal compared to dedicated platforms.

You should look elsewhere if: your data is distributed across multiple cloud providers or vendors (Purview is genuinely Microsoft-centric); your governance program is business-driven and requires strong collaboration between data stewards, business owners, and technical teams; you need purpose-based access controls or usage monitoring; or you’re evaluating a comprehensive data governance refresh and want to avoid lock-in.

If you’re comparing Purview specifically to Collibra or Alation, I’d recommend reading our Collibra vs Alation: 2026 Data Governance Buyer’s Guide, which walks through how traditional platforms stack up across discovery, lineage, compliance, and collaboration. Purview excels in a narrower lane—it’s optimized for Azure and Microsoft 365—while Collibra and Alation are optimized for cross-platform governance and business collaboration.

Real-World Implementation Considerations

In the field, I’ve observed a few patterns when teams implement Purview. First, the initial catalog scan is deceptively simple but often produces noisy results. You point Purview at your data sources, it catalogs everything, and suddenly you realize you have thousands of forgotten datasets and tables with no clear ownership. This is actually valuable—it forces you to confront your data landscape—but it can feel overwhelming. Plan for a data governance audit phase before you declare victory on the catalog.

Second, classification is the choke point. Out-of-the-box classifiers are good for obvious patterns but struggle with context. Teams often start with Purview’s built-in classifiers, apply them broadly, and then realize the false positive and false negative rates are high enough that manual review is necessary. If you’re planning to use classifications to drive DLP policies, invest in a strong classification governance process early—either by refining Purview’s classifiers extensively or by integrating a third-party classification tool.

Third, governance adoption is slow when Purview is the only tool. Because Purview is technical and catalog-focused, it often sits in IT’s domain. Business stakeholders don’t feel ownership over assets because they’re not part of the cataloging or classification process. If this matters to your program, you need a collaborative layer on top—whether that’s a business glossary, stewardship workflows, or an integration with a platform like Collibra that brings business users into the governance conversation.

Bottom Line

Microsoft Purview is a capable data governance engine that delivers real value for Azure-first and Microsoft 365-dependent organizations. If you’re building governance primarily within Microsoft’s ecosystem, Purview handles discovery, lineage, classification, and DLP enforcement well. But it’s not a replacement for enterprise data governance platforms like Collibra or Alation, and treating it as one typically leads to feature gaps and adoption problems down the line.

The question I ask my clients is simple: “Is Microsoft your primary data platform, or is it one platform among many?” If it’s primary, invest in Purview. If it’s one among many, treat Purview as a specialized tool that handles Azure and Microsoft 365 governance while a dedicated cross-platform governor orchestrates your broader governance program. This hybrid approach is operationally more complex, but it avoids the common trap of forcing non-Microsoft teams and data sources into a platform that wasn’t designed for them.

Pricing is attractive, integration is tight, and for the right use case, Purview is genuinely underrated. But clarity about what Purview does and what it doesn’t do—combined with honest assessment of whether your organization truly is a Microsoft-first operation—is where the real decision-making starts.

Frequently Asked Questions About Microsoft Purview

What is the difference between Azure Purview and Microsoft Purview?

Azure Purview was the original service name when Microsoft launched its data governance capability in 2020. As of 2023–2026, Microsoft rebranded and consolidated these capabilities under the umbrella name “Microsoft Purview,” which now spans the data catalog, compliance, and DLP features accessible through the Purview Portal. The underlying technology and Azure infrastructure remain the same; the name change reflects Microsoft’s broader positioning of Purview as a unified governance platform rather than a service limited to Azure.

Can Microsoft Purview catalog non-Microsoft data sources like Snowflake or Databricks?

Yes. Purview supports scanning a range of non-Microsoft sources including Snowflake, Databricks, on-premises SQL Server, PostgreSQL, Salesforce, and others through self-hosted integration runtimes. However, Purview’s compliance and DLP capabilities are primarily tied to Azure and Microsoft 365 services. You can catalog non-Microsoft data, but you cannot enforce DLP policies across those platforms using Purview alone.

How does Microsoft Purview compare to Collibra?

Purview is optimized for Azure and Microsoft 365 ecosystems and excels at technical data discovery and lineage. Collibra is a cross-platform governance platform with stronger collaborative stewardship tools, business glossary management, and multi-cloud support. If you’re exclusively on Azure and Microsoft 365, Purview may suffice. If you operate across multiple cloud providers or need deep business-IT collaboration, Collibra is typically the stronger choice.

Is Microsoft Purview a data catalog, a DLP tool, or a governance platform?

Purview is all three, but with different strengths. The data catalog and lineage capabilities are first-class. DLP enforcement in Microsoft 365 is strong. But as a comprehensive governance platform—with stewardship workflows, business glossaries, and policy orchestration—it’s limited compared to platforms like Collibra or Alation.

What is the cost of Microsoft Purview in 2026?

Purview uses consumption-based pricing. You pay per gigabyte of data scanned, per asset cataloged, and per classification or DLP policy evaluated. A typical enterprise with moderate usage pays $500–$3,000 monthly, significantly less than traditional seat-based governance platforms. Exact costs depend on scan frequency, data volume, and number of policies evaluated.

Does Microsoft Purview include a business glossary?

Purview includes minimal business glossary functionality. It allows you to create business terms and link them to technical assets, but it lacks the collaboration workflows, approval processes, and rich metadata enrichment found in dedicated platforms. For a robust glossary, consider integrating Purview with Collibra or supplementing it with a separate business metadata layer.

How does purview data lineage work across Azure services?

Purview automatically captures lineage for Azure-native services like Azure Data Factory, Synapse, Data Lake, and Fabric. When a Data Factory pipeline reads from a data lake and writes to Synapse, Purview traces the relationship without manual configuration. For non-Azure platforms or custom scripts, lineage capture requires additional integration or manual registration.

Purview supports compliance workflows including DLP, sensitivity labeling, and data classification, which contribute to GDPR readiness. However, Purview alone does not provide purpose-limitation controls, usage monitoring, or consent management. For comprehensive GDPR governance, combine Purview with additional tools and strong governance processes.