What is OneLake Catalog in Microsoft Fabric?

OneLake Catalog is the discovery and governance surface inside Microsoft Fabric for every item stored in OneLake — semantic models, warehouses, lakehouses, KQL databases, notebooks, and Data Factory pipelines. At Microsoft Build 2026 it went GA with the Govern tab, which adds data-product publishing, certification workflows, access reviews, and Microsoft Purview (Foundry) integration.

Do I still need Microsoft Purview if I have OneLake Catalog?

For most enterprises, yes. OneLake Catalog handles governance for items inside Fabric, but Purview handles cross-source discovery (Snowflake, Databricks, on-prem), data loss prevention (DLP), and full compliance reporting. If your entire data estate is in Fabric and you have no DLP requirements, OneLake Catalog may be sufficient. Otherwise both coexist and the Foundry integration keeps them in sync.

How much does OneLake Catalog cost?

OneLake Catalog is included with any Fabric F-SKU capacity at no additional cost. Catalog operations consume a small amount of CU from your existing capacity — typically less than 5% of total consumption, but measure in your environment.

What is a data product in OneLake Catalog?

A data product is a curated collection of Fabric items (semantic models, warehouses, or lakehouses) packaged as a single consumable asset with an owner, SLA, sensitivity label, business glossary tags, and a consumer list. Data products can be certified at three tiers (Promoted, Certified, Master) that determine which consumers can discover them.

How do sensitivity labels work in OneLake Catalog?

Sensitivity labels are inherited from Microsoft 365 Purview Information Protection. Labels applied to Fabric items propagate through derivations (a report using a labeled semantic model inherits the label) and sync bidirectionally with Purview via the Foundry integration. Users below the label's permission tier cannot see labeled items.

What is the Govern tab in OneLake Catalog?

The Govern tab is the new-at-GA workspace for data product owners. Publish data products, define certification tiers, run scheduled access reviews on consumer lists, and see lineage — all in one place. It sits between the Fabric admin center (admin-scoped) and Purview (compliance-scoped) and is optimized for data-product-owner workflows.

What are OneLake Catalog certification tiers?

Three tiers: Promoted (peer-reviewed, self-service), Certified (governance-team-reviewed), Master (data domain owner reviewed). The tier determines which consumers can discover the product. Best practice: reserve Certified for products with documented lineage, a measured SLA, and an on-call owner — otherwise the tier loses meaning.

How is a Power BI engagement priced for enterprise workloads?

Pricing is modeled against three variables: the complexity of the semantic layer, the volume and velocity of source data, and the governance footprint required after go-live. A scoped implementation typically runs as a fixed-fee discovery sprint followed by a time-and-materials build, because dataset refresh patterns and row-level security rules almost always evolve once real user personas review early drafts. Licensing is separated from consulting fees and mapped against Power BI Pro, Premium Per User, and Fabric capacity SKUs so finance teams can plan capacity uplift independently of delivery cost. A typical mid-market rollout lands between 120 and 480 consulting hours across data modeling, DAX optimization, report design, and deployment pipelines. Fabric workloads add capacity sizing sessions to avoid over-provisioning F-SKUs on day one.

How long does a production-ready Power BI rollout take?

A single subject-area workspace with a conformed star schema, deployment pipeline, and row-level security ships in roughly six to eight weeks once source access is granted. Multi-domain rollouts that span finance, operations, and customer analytics typically run three to five months because the semantic model has to reconcile calendar, product, and organizational hierarchies that rarely align across source systems. Fabric lakehouse projects add four to six weeks for medallion design, Direct Lake tuning, and OneLake shortcut setup. Timelines compress when an authoritative data dictionary already exists and lengthen when stakeholders are discovering definitions (for example, what counts as "active customer") for the first time. Governance, training, and center-of-excellence enablement are run in parallel rather than sequentially.

What delivery methodology do you use for Power BI and Fabric projects?

Delivery runs on a five-stage pattern: Discover, Model, Visualize, Operationalize, and Enable. Discover captures questions stakeholders actually want answered, not just source tables. Model builds a Kimball-style star schema (or a medallion lakehouse in Fabric) with conformed dimensions and documented grains. Visualize produces reports against a shared theme file, applies accessibility tokens, and uses bookmarks and field parameters instead of bespoke page duplication. Operationalize wires up deployment pipelines, dataset refresh monitoring, and Azure DevOps or GitHub source control via TMDL. Enable delivers hands-on training for citizen developers and a lightweight center-of-excellence charter. Each stage ends with a demo and a written acceptance checklist, so scope creep is visible before it becomes rework.

How do you secure sensitive data inside Power BI reports?

Security is layered rather than relying on a single control. Row-level security and object-level security are enforced inside the semantic model using DAX filter expressions driven by Entra ID group membership, so filters survive refresh and cannot be bypassed by report-level tricks. Sensitivity labels from Microsoft Purview are applied at dataset and report scope and follow exports into Excel and PDF. Workspace roles follow a least-privilege pattern (Admin, Member, Contributor, Viewer) and are granted to Entra ID groups, never individuals. Private endpoints and VNet data gateways keep on-premises sources off the public internet, and tenant-level settings restrict publish-to-web, external sharing, and guest access. Every production dataset is audited quarterly against a written RLS test plan.

Can existing Excel and Tableau reports be migrated into Power BI?

Yes, but a migration is an opportunity to redesign rather than a literal port. Excel financial models usually translate cleanly into a semantic model: named ranges become dimensions, pivot tables become matrix visuals, and SUMIFS chains become well-formed DAX measures with variables. Tableau workbooks require more interpretation because Tableau extracts and Power BI datasets have different refresh and relationship semantics; calculated fields are rewritten as DAX, LOD expressions become CALCULATE patterns, and dashboard actions are rebuilt using bookmarks and drillthrough. A discovery audit catalogs every report, ranks them by business value, and retires the long tail of duplicates before migration starts. This typically reduces the report estate by 30–50 percent.

How do you optimize DAX performance on large semantic models?

DAX performance starts with the model, not the measure. Star schemas with integer surrogate keys, single-direction relationships, and calculated columns materialized in Power Query outperform ambiguous snowflakes every time. Measures are written using variables (VAR/RETURN) to avoid repeated context transitions, and expensive patterns like FILTER over entire tables are replaced with KEEPFILTERS and Boolean filter arguments. Aggregation tables and composite models offload detail-level queries from imported caches to Direct Lake or DirectQuery sources. Every measure that appears in a production report is profiled with DAX Studio and VertiPaq Analyzer; queries above a 2-second threshold on representative hardware are rewritten before release. Fabric capacity metrics are reviewed weekly to catch runaway refreshes and interactive CPU spikes.

Do you support Microsoft Fabric, OneLake, and Direct Lake workloads?

Fabric is now the default landing zone for new analytics workloads unless a client has a specific reason to stay on legacy Power BI Premium capacity. Engagements cover medallion architecture design in lakehouses, data engineering pipelines built in Fabric notebooks or Dataflows Gen2, shortcut-based integration with Azure Data Lake Storage and Amazon S3 through OneLake, and Direct Lake semantic models that skip import refresh entirely. Capacity sizing is based on measured workload patterns rather than vendor rules of thumb, and F-SKU scaling is automated through Azure Logic Apps or the Fabric REST API so off-hours costs stay predictable. Copilot in Fabric is configured with tenant-level data boundaries and audit logging before it is enabled for end users.

What training and enablement do end users receive after go-live?

Training is tiered by persona. Report consumers get a 45-minute guided tour covering filters, bookmarks, subscriptions, and mobile access. Analysts get a three-session workshop on self-service semantic model extensions, composite models, and publishing to workspaces that follow the governance pattern. Data modelers receive a two-day immersion on star schema design, DAX fundamentals, and deployment pipeline usage. Every session is recorded, indexed, and paired with a sandbox workspace seeded with representative sample data. A written center-of-excellence charter defines who owns certified datasets, who can promote a report to production, and how to request enhancements. Office hours run for 30 days post-launch so questions do not pile up into a formal change request.

How are Power BI deployments managed across dev, test, and production?

Every production workspace is paired with matching development and test workspaces wired through Power BI deployment pipelines. Datasets are source-controlled as TMDL files in Azure DevOps or GitHub so pull requests can be reviewed by a second modeler before merge. Environment-specific parameters (connection strings, sensitivity label rules, capacity assignments) are swapped at deployment time using parameter rules rather than manual edits. Fabric deployment pipelines handle lakehouses, notebooks, and data pipelines with the same promotion pattern. Refresh schedules, gateway assignments, and alerting are applied through the Power BI REST API so they survive redeployment. A written change-management checklist covers dataset certification, dependency impact analysis, and rollback procedure for every promotion to production.

Which industries and data sources do you support most often?

Heaviest experience sits in healthcare, financial services, energy, manufacturing, and public sector, because each of those verticals pushes a different dimension of Power BI: HIPAA-bound PHI handling, transaction-grain reconciliation, time-series sensor data, cost-center-driven manufacturing variance, and FedRAMP-aligned government reporting. Source systems frequently include Microsoft Dynamics 365, SAP ECC and S/4HANA, Salesforce, Workday, Epic and Cerner (Oracle Health), Infor, and a long tail of legacy ODBC databases connected through on-premises data gateways. Fabric engagements add Azure Data Lake Storage, Snowflake, Databricks, BigQuery, and Amazon S3 through OneLake shortcuts. Regardless of source, the modeling discipline is identical: conformed dimensions, documented grains, and a semantic layer that hides the join complexity from report authors.

OneLake Catalog GA: Enterprise Governance Guide (2026)

OneLake Catalog went GA at Microsoft Build 2026, and it fills the last serious governance gap in the Fabric platform. Before GA, teams had to bounce between the Fabric admin center, Microsoft Purview, and manually maintained SharePoint pages to answer the "what data do we have, who owns it, and is it certified?" question. OneLake Catalog centralizes those answers inside the Fabric portal itself, and the new Govern tab at GA layered on data-product publishing, certification workflows, and Foundry integration. This is the first independent enterprise guide to the catalog, what changes at GA, how it fits alongside Purview, and how to roll it out in 12 weeks.

What OneLake Catalog Actually Is

OneLake Catalog is the discovery and governance surface for every item stored in OneLake — semantic models, warehouses, lakehouses, KQL databases, notebooks, Data Factory pipelines, and everything else you build in Fabric. It replaces the "OneLake data hub" that shipped with Fabric GA in 2024 and extends it with:

The Govern tab (new at Build 2026): the enterprise governance workspace inside the catalog. Publish data products, define certification tiers, run access reviews, and see lineage.
Foundry integration: the catalog now writes to and reads from Microsoft Purview Data Governance (formerly Purview Data Catalog, currently branded as "Foundry" in some documents). Business glossary terms, sensitivity labels, and lineage flow both directions.
Item-level tagging: attach business glossary terms, ownership, freshness SLAs, and certification tier to any Fabric item.
Certification workflows: request certification, review, approve, and publish — all inside the catalog rather than as a separate ticket process.
Discovery-oriented UI: the catalog leads with "what data do we have?" instead of "what workspaces exist?" — a subtle but important shift for business users who don't think in workspace boundaries.

The high-level mental model: OneLake Catalog is the "front door" for data consumers, and Purview is the "control plane" for compliance officers. They share a database of business glossary terms, tags, and lineage — but they serve different audiences.

What Went GA at Build 2026

Three things changed at GA that matter for enterprise governance decisions:

1. The Govern tab. Before GA, governance workflows lived in the Fabric admin center (for admins) or Purview (for compliance officers). At GA, the Govern tab in OneLake Catalog gives *data product owners* a workspace that's neither admin nor compliance — it's product-owner-scoped. Publish a data product, define its consumers, set its SLA, run access reviews on the consumer list. This shifts governance responsibility to the people closest to the data, which is the pattern every mature data mesh implementation converges on.

2. Foundry integration. Sensitivity labels, business glossary terms, and lineage now flow between Fabric and Purview automatically. Applying a "Confidential — Financial" sensitivity label to a semantic model in Purview propagates to the same model in Fabric within seconds. Adding a business glossary term to a Fabric warehouse column shows up in Purview's glossary browser. Before GA, you maintained these separately or wrote sync jobs.

3. Access reviews. OneLake Catalog can now run scheduled access reviews on any published data product. The catalog emails each consumer periodically ("do you still need access to this data product?"), auto-revokes if there's no response, and logs the audit trail. This is the workflow compliance officers were writing custom Power Automate flows for; now it's native.

OneLake Catalog vs Microsoft Purview

The most common architect question is: "if OneLake Catalog does governance now, do I still need Purview?" The honest answer: yes for most enterprises, and here is why.

Capability	OneLake Catalog	Microsoft Purview
Fabric item discovery	Native	Via connector
Non-Fabric data source discovery (Azure SQL, Snowflake, Databricks, S3)	No	Yes
Business glossary	Yes (Fabric-scoped)	Yes (enterprise-scoped)
Sensitivity labels	Yes (Fabric-scoped)	Yes (all Microsoft 365 + connected sources)
Data lineage	Yes (within Fabric)	Yes (cross-source)
Certification workflows	Yes	Yes
Access reviews	Yes (data product scope)	Yes (identity scope)
Compliance reporting (audit exports)	Limited	Full
Data loss prevention (DLP)	No	Yes
Data-map crawling of on-prem sources	No	Yes

When you can drop Purview: your entire data estate is inside Fabric, you have fewer than ~50 non-Fabric data sources, you are not subject to strict DLP requirements. This is a small minority of enterprises.

When you keep both: you have any Snowflake, Databricks, Azure SQL, or on-prem data sources; you have DLP requirements; your compliance officer needs audit exports Purview specializes in. This is the majority. OneLake Catalog and Purview coexist happily; the Foundry integration keeps them in sync.

How to Publish a Data Product in OneLake Catalog

Data products are the most valuable new concept in the Govern tab. A data product is a curated collection of Fabric items — one or more semantic models, warehouses, or lakehouses — packaged as a single consumable asset with an owner, SLA, and consumer list.

The publish flow:

Design the data product. Decide what business question it answers ("customer 360 for the marketing team") and which Fabric items feed it. Typical: one semantic model + optional supporting warehouse.
Set metadata. Description, owner, business glossary terms, sensitivity label, SLA (refresh frequency + freshness target), documentation link.
Request certification. Choose a tier: Promoted (peer-reviewed), Certified (governance-team-reviewed), or Master (data domain owner reviewed). The tier determines which consumers can discover the product.
Approve certification in the Govern tab (this step is done by whoever owns the certification tier).
Publish. The product appears in the OneLake Catalog for its allowed audience.
Set access reviews. Optional but recommended — auto-review consumer access every 90 or 180 days.

Certification tiers are the most under-used feature. Most enterprises publish everything at "Promoted" and never enforce a Certified tier. The right pattern: reserve Certified for products that have documented lineage, an SLA that's actually measured, and an on-call owner. Otherwise "certified" means nothing.

Sensitivity Labels and How They Flow

Sensitivity labels in OneLake Catalog inherit from Microsoft 365 Purview Information Protection. If you have already deployed sensitivity labels for documents (Confidential, Highly Confidential, etc.), those labels now apply to Fabric items:

Applying a label: any user with permission to edit an item can apply a label from the Catalog UI, from Fabric Desktop, or from Purview.
Downstream propagation: labels flow through Fabric derivations. If a semantic model uses tables from a lakehouse with "Confidential" label, the semantic model inherits the label. Downstream reports do too. Users below the label's permission tier cannot see the report.
DLP integration happens through Purview (not directly in OneLake Catalog). If your compliance policy requires DLP scans, keep Purview.

The one nuance: labels applied in Fabric propagate up to Purview within seconds via Foundry integration. Labels applied in Purview propagate down to Fabric within seconds. In steady state you don't care which UI you used.

12-Week Enterprise Rollout Playbook

If you are deploying OneLake Catalog governance across an enterprise for the first time:

Weeks 1-2: Discovery. Inventory every Fabric workspace, semantic model, warehouse, and lakehouse. Identify owners for each. Identify the top 20 "data products" that consumers actually depend on today.

Weeks 3-4: Governance-council setup. Establish the data governance council (typically 4-6 people spanning IT, business analytics, compliance, legal). Agree on certification tier definitions, sensitivity label taxonomy, and the SLA framework you will hold data products to.

Weeks 5-6: Foundry integration. Enable the Fabric ↔ Purview integration in the Fabric admin center. Import your Purview business glossary and sensitivity labels. Confirm bidirectional sync.

Weeks 7-9: Data product publishing (top 20). For each of the 20 data products identified in weeks 1-2, walk through the publish flow. Assign owners, set metadata, request certification, define access reviews. Expect this phase to surface a lot of "who owns this?" questions — that surfacing is the point.

Weeks 10-11: Consumer training. Train business users on catalog discovery. Show them how to find data products, how to request access, and how to interpret certification tiers. Adoption depends on this step; skip it and the catalog becomes a compliance formality nobody uses.

Week 12: Steady-state operations. Access reviews start firing. Refresh SLA monitoring surfaces the first failures. Certification requests start flowing from other teams. Retrospective and adjust.

Production Readiness Checklist

[ ] Foundry integration enabled and bidirectional sync verified (labels, glossary, lineage).
[ ] Sensitivity label taxonomy documented and applied to at least 90% of certified data products.
[ ] Certification tier definitions written down and shared with data product owners.
[ ] At least 10 top-priority data products certified at Promoted or higher.
[ ] Access reviews configured on all Certified and Master tier products.
[ ] Data lineage confirmed accurate for top 20 products (spot-check the visualization).
[ ] Business glossary populated with the top 200 enterprise terms.
[ ] Catalog UI training completed for at least 50% of active Fabric users.
[ ] Compliance officer confirms the Purview + Catalog combination meets audit requirements.
[ ] Fabric capacity has headroom for catalog operations (typically <5% of total CU, but measure).

Related Guides

Ready to roll out OneLake Catalog governance in your Fabric estate? Book a 30-minute strategy call and we will scope a 12-week rollout for your data product portfolio.