{"slug": "unity-catalog-metric-views-now-in-power-bi-one-unified-governed-semantic-layer", "title": "Unity Catalog Metric Views, now in Power BI: one unified, governed semantic layer for all your reporting and AI", "summary": "Databricks introduced Publish to Power BI, a feature that lets customers connect Unity Catalog metric views directly to Power BI semantic models, with each metric view becoming a table, its dimensions becoming columns and its measures becoming DAX measures. The feature, detailed by Toussaint Webb, Joanna Zouhour, Chris Eubank and Jade Wang, keeps the metric view as the source of truth so that joins defined in the metric view run in Databricks, and it can be run on demand from Catalog Explorer or scheduled as a Power BI task in a Lakeflow Job to keep metric views and semantic models in sync in production. Databricks said the change addresses organizations running thousands of Power BI workspaces with their own semantic models, where duplicated metric logic causes reports to drift and every definition change requires updating each copy.", "body_md": "Define semantics once in Unity Catalog and publish them directly to Power BI semantic models\n\nby   [Toussaint Webb](https://www.databricks.com/blog/author/toussaint-webb), [Joanna Zouhour](https://www.databricks.com/blog/author/joanna-zouhour), [Chris Eubank](https://www.databricks.com/blog/author/chris-eubank)  and  [Jade Wang](https://www.databricks.com/blog/author/jade-wang) \n\nOrganizations want a single, trusted definition of their business semantics. Revenue, margin, and active customers should mean the same thing in every report, notebook, and AI application. When they don't, business users and AI agents read the same data differently and reach different answers. Finance and sales show different revenue numbers, teams lose trust in their reports, and decisions get made on the wrong numbers. [Unity Catalog metric views](https://learn.microsoft.com/en-us/azure/databricks/uc-semantics/metric-views/), part of Unity Catalog semantics, solve this by enabling customers to define business KPIs once in Databricks, in an open, governed semantic layer that sits on top of the lakehouse.\n\nAt the same time, many of these organizations rely on Power BI as the front end for their business users. Often, organizations have thousands of PowerBI workspaces each with its own Semantic Models, creating a governance and unification nightmare. Furthermore, when each team builds its own metrics and relationships in Power BI, the same logic lives in many places. Reports drift apart, and every definition change means updating each copy.\n\nCustomers have told us they want both: Databricks as their unified, open semantic layer, and Power BI as their front end. With **Publish to Power BI**, they can now have both. Every Power BI report uses the same governed UC metric views as AI/BI dashboards and Genie, so teams work from consistent numbers. Business users can build self-serve reports and explore metrics across any dimension without waiting on a data team to model data or write DAX. Data teams maintain one definition in Databricks instead of many copies across systems. Publish on demand from Catalog Explorer, or add a Power BI task to a [Lakeflow Job](https://learn.microsoft.com/en-us/azure/databricks/jobs/) to keep metric views and semantic models in sync in production.\n\nWith Publish to Power BI or a Power BI task, you can connect Unity Catalog metric views to a Power BI semantic model. Each metric view becomes a table in the model. The metric view’s dimensions (aka Fields) become columns and its measures become DAX measures.\n\nPower BI queries the metric view itself (as if it was a table). The metric view stays the source of truth, and joins defined in the metric view run in Databricks. Joined dimensions, such as campaign channel or region, show up in Power BI as ordinary columns, so you don't have to rebuild table relationships in Power BI.\n\nFor example, a marketing team needs to track campaign performance and decide where to shift budget. They define a campaign_performance metric view in Unity Catalog with dimensions such as channel and region and measures such as total spend, total revenue, and return on ad spend (ROAS). When the team publishes the metric view, those dimensions and measures arrive in Power BI like this:\n\n| **Category** | **Metric view expression** | **Power BI measure (DAX)** | \n|---|---|---|\n| Dimension | channel (from the joined campaigns table) | ‘campaign_performance'[channel] | \n| Dimension | region (from the joined regions table) | 'campaign_performance'[region] | \n| Measure | total_spend = SUM(spend) | total_spend = SUM('campaign_performance'[spend]) | \n| Measure | total_revenue = SUM(revenue) | total_revenue = SUM('campaign_performance'[revenue]) | \n| Measure | roas = MEASURE(total_revenue) / MEASURE(total_spend) | roas = DIVIDE([total_revenue], [total_spend]) | \n\nA marketing analyst can then build a Power BI report that compares ROAS by channel and region, and see the same numbers the team gets in AI/BI dashboards and Genie. If the team later changes what counts as total_revenue they update the metric view once, a Power BI task in their pipeline republishes it, and every Power BI report picks up the new definition.\n\nBecause Power BI queries the metric view, it will soon be able to benefit from metric view materialization too. Metric view materialization is a performance optimization that pre-computes results without changing how metrics are calculated. When Power BI sends a query, Databricks will serve it from a matching materialization for faster results. If no materialization matches, the query runs against the metric view as usual. Either way, the metric definitions, DAX measures, and results are identical.\n\nAdditionally, with Lakehouse//RT + DirectQuery, Power BI reports get real-time performance, directly on your governed lakehouse data. Lakehouse//RT runs on your managed Delta tables, so there's no separate serving system to copy data into or manage. It also enforces the same Unity Catalog row filters, column masks, and ABAC policies, so reports get faster without giving up governance.\n\nWith DirectQuery, every query honors Unity Catalog access controls and security policies, and lineage stays connected to the metrics your teams already use in [AI/BI dashboards](https://www.databricks.com/product/business-intelligence), [Genie](https://www.databricks.com/product/genie/one), and [Databricks Lakehouse](https://www.databricks.com/product/databricks-lakehouse).\n\nWhen a metric view changes, we make it easy to keep Power BI up to date. Using [Power BI tasks](https://learn.microsoft.com/en-us/azure/databricks/jobs/tasks/powerbi) in Lakeflow Jobs, you can publish your metric views to the target semantic model as a step in your data pipeline, on a schedule or right after upstream tables refresh. Updated measures, new measures, and new dimensions flow into Power BI automatically, so reports stay aligned with the metrics layer without manual rework.\n\nPublish to Power BI covers the metric definitions most teams use day to day:\n\nPublish to Power BI is available in Private Preview ([documentation](https://learn.microsoft.com/en-us/azure/databricks/partners/bi/power-bi/publish-metric-views)). Work with your account team to test out the preview. \n\nOnce enabled, you can publish in three easy steps:\n\nTogether, these capabilities make Databricks the home of your semantics. Define your metrics once in Databricks, keep Power BI models in sync using Power BI tasks, and use the same governed definitions everywhere, including the Power BI reports business users already rely on. Every team and use case works from one open, governed platform.\n\n**What is a governed semantic layer, and why do BI and AI agents need one?**\n\nA governed semantic layer is one place where business metrics and shared dimensions like revenue, country, and active customers are defined. Every BI tool, notebook, and AI agent then uses those definitions the same way. Unity Catalog Semantics is that layer in Databricks. It brings together metric views, relationships, and other modeling metadata in Unity Catalog. It's open, you can query it with SQL, and it inherits Unity Catalog access controls and lineage. That's why a Power BI report, an AI/BI dashboard, and a Genie One agent all return the same ROAS number.\n\n**How do you give AI agents and BI users the same business definitions?**\n\nBuild business definitions once in a shared semantic layer that is accessible by all of your tools. Don't encode it separately in each BI tool or agent prompt. With Unity Catalog metric views, Genie One and Agent Bricks agents read the same governed definitions that Power BI reads through Publish to Power BI. When a definition changes, every consumer gets the update. \n\n**Should metrics live in Power BI semantic models or in Unity Catalog?**\n\nKeep the metric definitions in Unity Catalog. A Power BI semantic model primarily serves Power BI. It is hard to access from external BI tools or AI agents, requiring the same metric to be rebuilt in every tool. Publishing metric views to Power BI turns each measure into DAX automatically, so Power BI users keep their reports, while maintaining a single governed definition for AI and other use-cases.\n\n**Does Power BI query the metric view or the underlying tables?** \n\nThe metric view. Only the measure expressions are translated to DAX, and they reference the metric view's dimensions. The metric view stays the source of truth, and joins and calculations run in Databricks.\n\n**What does the published semantic model look like?**\n\nEach metric view becomes one table. Its dimensions become columns and its measures become DAX measures. Because joins are defined once in the metric view, joined dimensions show up as ordinary columns and no Power BI relationships are needed. For example, SUM(amount) becomes SUM('sales_metrics'[amount]), and MEASURE(a) / MEASURE(b) becomes DIVIDE([a], [b]).\n\n**What happens when a metric view changes?** \n\nTo keep models in sync automatically, add a [Power BI task](https://learn.microsoft.com/en-us/azure/databricks/jobs/tasks/powerbi) to a Lakeflow Job so publishing updates runs on a schedule or after upstream tables refresh.\n\n**Is access still governed by Unity Catalog?** \n\nYes, with DirectQuery. Every query honors Unity Catalog access controls and security policies. In Import mode, data is loaded into Power BI, so access to that copy follows Power BI permissions. \n\n**Do changes made in Power BI sync back to Unity Catalog?** \n\nNo. To ensure unified and governed semantics, publishing only goes one way, from Unity Catalog to Power BI. If you edit a published measure in Power BI, that edit isn't written back to the metric view. To change a governed metric, update the metric view in Databricks and republish, or create a Lakeflow Job with a Power BI task to update the Power BI semantic model on a schedule. \n\nSubscribe to our blog and get the latest posts delivered to your inbox.", "url": "https://wpnews.pro/news/unity-catalog-metric-views-now-in-power-bi-one-unified-governed-semantic-layer", "canonical_source": "https://www.databricks.com/blog/unity-catalog-metric-views-now-power-bi-one-unified-governed-semantic-layer-all-your-reporting", "published_at": "2026-11-10 18:45:00+00:00", "updated_at": "2026-11-10 19:24:02.849389+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-products", "ai-tools", "structured-data"], "entities": ["Databricks", "Unity Catalog", "Power BI", "Microsoft", "Catalog Explorer", "Lakeflow", "Genie", "Toussaint Webb"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/unity-catalog-metric-views-now-in-power-bi-one-unified-governed-semantic-layer", "markdown": "https://wpnews.pro/news/unity-catalog-metric-views-now-in-power-bi-one-unified-governed-semantic-layer.md", "text": "https://wpnews.pro/news/unity-catalog-metric-views-now-in-power-bi-one-unified-governed-semantic-layer.txt", "jsonld": "https://wpnews.pro/news/unity-catalog-metric-views-now-in-power-bi-one-unified-governed-semantic-layer.jsonld"}}