What Microsoft Purview Does for Data Governance

Microsoft Purview gives organisations a shared place to discover, describe and govern data across a distributed estate. Its current data governance offer centres on two connected solutions: Data Map captures technical metadata, while Unified Catalog turns that metadata into a business-facing governance experience.

That distinction matters. Purview can provide visibility and operating controls, but it does not replace the source platforms, establish accountability on its own or make poor data accurate by cataloguing it.

Purview data governance at a glance

Microsoft's data governance overview is the best starting point for the current product model. Organisations with an older implementation should check whether guidance refers to the new Microsoft Purview portal and Unified Catalog or the classic governance experience.

Data Map creates the metadata foundation

Microsoft Purview Data Map captures metadata from supported analytics, SaaS and operational systems across hybrid, on-premises and multicloud environments. Scans can collect technical details such as asset names, schemas, columns and classifications. Supported integrations can also contribute lineage.

This answers questions such as:

• What data assets exist across the sources we have connected?
• Where is potentially sensitive information located?
• Which reports or downstream assets may depend on a source?
• Which assets have owners, descriptions or classifications missing?

The Data Map stores metadata, not a second copy of all underlying data. Its value depends on scan coverage, credentials, schedules, source support and the quality of the metadata being collected. An unscanned system remains outside the view. A scanned column called CUST_STAT_CD remains hard for a business user to interpret until someone adds context.

Unified Catalog makes metadata useful to the business

Unified Catalog is the SaaS experience used to curate and consume the governance context held around the data estate. It provides tools for data access, curation, health and understanding.

The practical objective is not to expose every technical asset to every employee. It is to publish useful, governed data products that people can find and understand without relying on personal knowledge of systems.

A curated entry should tell a consumer what the data is for, who owns it, what it contains, how healthy it is and how access works. If the catalogue cannot answer those questions, search alone will not create trust.

Governance domains establish manageable boundaries

A governance domain is a boundary for the ownership, discovery and governance of data products and business concepts. A domain might represent finance, customer, workforce, supply chain or another area that matches how accountability works.

Domains support a federated model. A central data function can set common controls while domain owners and stewards manage the data they understand.

The choice of boundary is an operating-model decision. Copying the organisation chart can create too many domains, while putting everything into one enterprise domain can return every decision to a central team. Start with the areas that own the first important data products and expand only when the accountability is real.

Data products package assets around a use case

Microsoft defines a data product in Unified Catalog as a group of assets, such as tables, files and Power BI reports, with a defined use case that can be shared with users.

This is more useful than asking a manager to navigate thousands of tables. A "Monthly revenue performance" data product might bring together an approved semantic model, its relevant tables, business definitions, owner, quality status and access process.

A data product should have:

• A named business use case and intended consumers.
• One accountable owner.
• Clear included assets and authoritative sources.
• Relevant glossary terms and critical data elements.
• Quality expectations and refresh information.
• Access conditions and support contact.
• A review or retirement date.

Purview provides the structure. The product becomes trustworthy only when those details are maintained.

Glossary, critical data and objectives add meaning

Technical metadata describes systems. Business concepts describe why the data matters.

Unified Catalog can connect data products and assets to glossary terms, critical data elements and objectives. This helps distinguish, for example, the approved definition of active customer from similarly named fields in several applications.

Lineage supports impact and root-cause analysis

Lineage shows relationships between data sources, transformations and downstream assets where the relevant integration can capture them. It can help a team assess the effect of a source change or trace a quality issue towards its origin.

Use lineage to answer a decision, not to produce an impressive diagram. Before changing a finance source field, identify the affected pipelines, models and reports. During an incident, identify which downstream products may contain the same fault.

Coverage is not automatic for every custom process or unsupported source. Check the current Data Map source and feature guidance against the actual estate, then define how material gaps will be documented.

Data quality measures agreed rules

Data quality in Unified Catalog supports profiling, rules and scores that can be viewed across assets, data products and governance domains. Microsoft also documents recommendations that assist profiling, with human input retained.

Useful quality rules are specific to a use case:

• Invoice number must be present and unique before payment reporting.
• Settlement date cannot precede transaction date.
• Customer region must use an approved code set for territory reporting.
• A daily operational feed must arrive by an agreed time.

The score identifies a condition. It does not correct the source process, contact the responsible team or decide whether a report should be held back. That remediation loop remains an organisational responsibility. Data quality processing can also create usage charges, so profiling and rules should target material data rather than run without priority.

Access needs careful interpretation

There are two different permission questions.

First, who can administer, curate or read metadata in Purview? Microsoft's roles and permissions guidance covers organisation, Unified Catalog and Data Map permissions and recommends least-privilege roles.

Second, who can access the underlying business data? Catalog roles do not automatically grant that access. Unified Catalog data product access policies can manage requests and grant access in supported scenarios, but source support and configuration matter. Existing Azure or Fabric resource permissions can also affect what a user can see.

Treat Purview as part of the access model, not proof that every underlying system is controlled through one switch. Test approval, provisioning, expiry and revocation against each source included in the first data product.

Health management provides oversight

Unified Catalog health management brings together controls, data quality, actions and reports. Central owners can define controls while domains execute them, which fits a federated approach.

Health reporting is useful only when gaps have owners, due dates and a review cadence.

What Purview does not do

Purview does not:

• Decide which business outcomes deserve priority.
• Make a business executive accept data ownership.
• Resolve competing definitions between departments.
• Repair source processes that create poor-quality data.
• Guarantee lineage or policy enforcement across every technology.
• Replace privacy, security, legal or records-management judgement.
• Create adoption simply because a catalogue is available.

Those are not reasons to dismiss the platform. They are reasons to implement it against a clear data governance strategy.

A sensible first Purview scope

For a mid-market organisation, begin with one governance domain and one material data product. Connect only the sources required for that outcome. Confirm scan and lineage coverage, assign owner and steward roles, add the business terms that matter, define a small set of quality rules and test the real access path.

Measure whether users can find, understand and gain appropriate access to the product, and whether owners resolve quality issues. Then decide whether the pattern warrants expansion.

If the platform, ownership or first use case is unresolved, a Data Discovery & AI Readiness Roadmap can produce the target operating model and implementation sequence. If the outcome is ready, Microsoft Fabric consulting and implementation can establish the working data foundation inside the organisation's Microsoft environment.

Book a 30-minute fit call to determine whether Purview is the next requirement or whether a narrower data outcome should come first.