Purview Data Catalog

Microsoft Purview Unified Catalog

The Unified Catalog provides business-friendly data discovery and governance on top of the Data Map: organising assets into governance domains and data products with glossary terms, ownership, and data quality. This skill is the catalog/business layer; the Data Map (purview-data-map) is the technical scanning layer underneath.

When to use

Use this skill when the user wants analysts and data consumers to find, trust, and request data - not when they want to scan sources (that is the Data Map's job).

Do not use this skill for:

• Scanning lakehouses, databases, SaaS sources (use purview-data-map)
• Sensitivity labels for security/compliance (use purview-data-classification)
• Lifecycle/retention rules (use purview-data-lifecycle)
• AI data discovery (use purview-dspm-ai)

Pick the right object for the job

Rule of thumb: start with 1-2 governance domains and 5-10 data products. A catalog with 200 thinly-curated products is less useful than one with 10 great ones. Curation depth beats catalog breadth, every time.

Approach

A catalog rollout dies when IT "loads everything" without business ownership. Follow the order; each step gates the next.

1. Pre-requisite: Data Map is scanning and producing technical metadata — The Unified Catalog sits on top of the Data Map. Confirm scans are running, lineage is populating, and classifications are firing before designing domains. Verify: Data Map shows scanned assets with classifications (e.g. "Credit Card Number") and at least one lineage link source → sink.
2. Pick the right governance domains — Start with 2-3 high-pain business areas, not the org chart. Good first picks: Finance (regulatory pressure), Customer (consent and CRM sprawl), HR (privacy). Each domain needs a named business owner who has time, not a delegated IT proxy. Verify: each domain has a named accountable owner from the business side with a recurring 30-min weekly slot for curation.
3. Publish 3-5 data products per domain — A data product groups related assets for a specific consumer use case (e.g. "Customer 360 for marketing analysts"). Each product has: description, glossary terms linked, owner, access guidance, and at least one data quality rule on a key column. Do not publish empty shells. Verify: a representative consumer can find the product, understand what is in it, and request access via the in-portal workflow without external help.
4. Build the glossary in parallel, not first — Building a 500-term glossary up front produces a graveyard of terms with no asset links. Define terms as you build products; each term must link to at least one data product or asset at publication. Verify: every published glossary term is linked to ≥1 data asset.
5. Assign stewardship with named individuals, not teams — "Owned by the data team" = owned by nobody. Each governance domain and data product has a single named steward. Stewardship workload should be < 4 hours/week per steward, or it stops happening.
6. Configure data quality on critical data elements only — Do not scan everything. Pick 5-10 critical data elements per data product (e.g. customer_id, order_amount, date_of_birth) and define rules: completeness, uniqueness, validity, freshness. Publish the score on the product page. Verify: each high-priority data product shows a quality score and the rules behind it.
7. Drive adoption with discoverability — Wire the catalog into Power BI (catalog endorsement surfaces in the BI service), Microsoft Search, and Teams. If consumers cannot find products where they already work, they will not use the catalog. Verify: a Power BI dataset surfaces its catalog endorsement; a Teams search returns a linked data product.
8. Operate as a continuous programme — Monthly: review unowned assets, stale products, broken lineage. Quarterly: domain owner check-in on curation completeness. Annually: sunset retired products.