Author Archives: Alexander Korn

Jumpstart Your Fabric Environment: A Real Demo on Real Data — in One Line

Jumpstart your Fabric environment with a real demo on real data — in a single line.

import fabric_jumpstart as jumpstart
jumpstart.install("hochschul-insights")

About three minutes later you have a complete German higher-education analytics stack in your workspace — a Lakehouse, a Direct Lake semantic model, an 8-page IBCS report with an Azure Map of all 422 Hochschulen, a pipeline and a Data Agent — all built on real public DESTATIS GENESIS data. No toy sample data, no manual wiring.

This is the first in a new Fabric Demo Series — small, opinionated, end-to-end demos that you can install into your own Microsoft Fabric workspace in a single click and play with right away. More demos coming soon (Defense, Retail, Health, Automotive — all GENESIS-powered).

What is Hochschul-Insights?

A complete German higher-education analytics demo, built on real public DESTATIS GENESIS data, enriched with Wikidata (city + geo) and wrapped in an IBCS-styled Direct Lake report. Eight pages, an Azure Map, a Data Agent for natural-language Q&A, and a single notebook to deploy the whole thing.

Hochschul-Insights report home page

What you get in your workspace

  • Lakehouse hochschul_insights_lh (schemas enabled, schema Genesis) with 16 Delta tables (10 facts, 6 dimensions).
  • Notebooks — an 00_start_here entry point, a snapshot loader, the GENESIS Loader (DESTATIS REST API) and a Wikidata-enriched Dimensions notebook.
  • Data Pipeline hochschul_insights_pipeline orchestrating parallel loads.
  • Direct Lake Semantic Model HochschulInsights with calculated calendar + IBCS measures.
  • Report HochschulInsights — 8 pages, IBCS layout, Azure Map of all 422 Hochschulen.
  • Data Agent hochschul_stats_agent for natural-language Q&A on the model.

Two install modes

The installer supports two flavours, and you pick by whether you paste a token or leave it empty:

  • Snapshot mode (default, no token) — loads bundled CSV snapshots from the public GitHub repo. Fastest path to “look at the report”, no signup needed. Finishes in a few minutes.
  • Live mode (free DESTATIS token) — runs the real pipeline: pulls fresh data from DESTATIS GENESIS, enriches with Wikidata, lands Delta, refreshes the model. ~10–15 minutes end-to-end. Schedule weekly afterwards.

How to install

Hochschul-Insights is now an official community Fabric Jumpstart, so the recommended path is a single line of Python.

Recommended — one line via Fabric Jumpstart

In any Fabric notebook:

%pip install -q fabric-jumpstart

import fabric_jumpstart as jumpstart
jumpstart.install("hochschul-insights")

About 3 minutes later (snapshot mode) the whole stack lands in a single hochschul-insights workspace folder. Then:

  1. Open the hochschul-insights folder and the 00_start_here notebook.
  2. (Optional, live mode only) register at www-genesis.destatis.de, copy your free username token and paste it into the parameters cell. Leave it empty for snapshot mode.
  3. Hit Run all, then open the HochschulInsights report.

No az login, no pip install, no environment variables — the Jumpstart authenticates via notebookutils, auto-detects your workspace and deploys everything. To clean up, just delete the hochschul-insights folder; every item lives inside it.

In live mode you can watch the pipeline run from the same notebook — three parallel GENESIS loads, then the dimensions builder, then the semantic model refresh:

Hochschul-Insights data pipeline

A peek at the report

Eight pages, all IBCS-styled. Here is the live report — click around, it is the real thing (Publish to web, all public DESTATIS data):

Three pages are worth pointing out as you click through the embed above:

  • Home — the landing page: KPIs and a Top-10 university ranking. The hero block here is drawn by a self-made HTML viewer visual (more on that below).
  • Übersicht — totals across all 16 Bundesländer plus an Azure Map of all 422 institutions (lat/lon from Wikidata, City fallback).
  • Studenten — student counts broken down by Fächergruppe, Bundesland, Hochschulart and gender, with cross-filter scenarios baked in.

A self-made IBCS custom visual — built in a few prompts

The multi-tier bar chart on the Studenten page isn’t off-the-shelf — I built that custom visual myself, and that is almost the best part of the story: it went from “I wish Power BI had this” to working-on-the-page in well under an hour, with just a handful of prompts to an AI coding assistant.

It’s a purpose-built IBCS custom visual: AC bars with PY/PL reference markers and Δ / Δ% variance tiers, semantic green/red, all following the IBCS notation standard. It ships in two orientations — horizontal (bar) and vertical (column) — exactly the integrated variance chart the IBCS world loves and stock Power BI doesn’t include. One caveat: at the time of writing it isn’t scrollable yet, so very long category lists get clipped — that’s on the roadmap.

The takeaway: rolling your own Power BI custom visual used to be a side project. With an AI coding assistant it’s an afternoon — often less.

HTML viewer on the Home page

The hero block on the Home page is rendered by an HTML content viewer custom visual: it takes a measure that returns HTML/CSS and renders it live inside the report. That’s how the landing page gets its own typography, KPI tiles and layout without ever leaving Power BI. This one I didn’t build myself — it’s an existing custom visual — but it pairs perfectly with the self-made IBCS chart.

Behind the scenes — what makes this fun

  • Direct Lake on schemas-enabled lakehouse — no import, no scheduled refresh of the model.
  • Wikidata SPARQL for Hochschule geolocation (EF1 + lat/lon, City fallback for the half-dozen missing ones).
  • IBCS measures — units calc group, semantic colours, scenario shading.
  • Loader notebook is pure PySpark + requests + pandas — no add-ons, runs on the default Fabric runtime:

Hochschul-Insights GENESIS Loader notebook

Take it further — build your own

Don’t stop at this demo. Open GENESIS-Online, pick any of the thousands of other tables, swap them into the loader notebook and you have your own end-to-end report in an afternoon. GENESIS is a gold mine: population, labour market, energy, prices, foreign trade, construction, healthcare, agriculture, tax, transport — there is something relevant for every company. Use this demo as the template, point it at the stats that matter for your business, and ship.

Your turn — contribute your solution

The Fabric Jumpstart catalog is a community effort, and this demo is my contribution. Big thanks to Miles Cole for the guidance that got Hochschul-Insights into the catalog — the whole process was smooth because of it. If you have built something end-to-end on Fabric, package it as a Jumpstart so anyone can install it in a single line. So: when will you contribute your solution?

Get it

Fabric Jumpstart (one-line install): jumpstart.fabric.microsoft.com/catalog/hochschul-insights

Source repo: github.com/KornAlexander/hochschul-insights

Data licence (DESTATIS GENESIS): Datenlizenz Deutschland 2.0 — commercial use OK with attribution.

From Idea to an IBCS Custom Power BI Visual — in 5 Prompts

Hochschul-Insights report landing page showing the IBCS integrated variance bar visual with AC, PY, delta and delta-percent tiers

Q: Can you build a real, IBCS-compliant Power BI custom visual without writing the TypeScript yourself?
A: Yes. I built two of them — a vertical integrated variance column chart and its horizontal bar sibling (AC vs PY/PL/BU with Δ and Δ% tiers, semantic green/red, IBCS scenario notation) — by driving an AI coding agent through five focused prompts: research → scaffold → core implementation → IBCS polish → format pane + packaging.

The result is a working, packageable .pbiviz you can drop into any report. Code, plan, and self-test strategy are public in the repo.

And the kicker: the whole thing took no more than an hour. That’s the real headline — not that an agent can build a custom visual, but that it can do it in the time it takes to drink a coffee and read your email. Imagine what’s possible with a full day, or a few of them.

Honest disclaimer: “5 prompts” is the shape of the journey, not a literal keystroke count. Each prompt kicked off a chunk of work that I reviewed, corrected, and iterated on. The point is the workflow, not a magic one-shot.

Why build this at all?

The IBCS “integrated variance” layout — Actual vs. a reference (PY / PL / BU) with the absolute delta (Δ) and the relative delta (Δ%) stacked as separate tiers on a shared category axis — is the single most useful chart in management reporting. The established commercial custom visuals do it beautifully, and they’re the de-facto gold standard.

But I wanted to understand how much of that chart an AI agent could build from scratch, as an open, inspectable reference: pure-TypeScript variance math, IBCS scenario notation (AC solid, PY outlined, PL/BU hatched, FC dotted), semantic positive/negative color, and two orientations sharing ~90% of the code.

So the goal was never “replace the commercial visuals.” It was: prove the build path, and end up with a clean, hackable visual.

The 5 Prompts

Prompt 1 — Research & plan (no code yet)

“Here’s an IBCS integrated-variance reference image and a research doc. Produce a build plan: define what ‘multi-tier’ means, map the feature set against the leading commercial IBCS visuals as the north star, and split it into MVP / Phase 2 / out-of-scope.”

This produced PLAN.md — including a 28-row capability map (researched against the established commercial IBCS visual providers) and a strict v0.1 subset. Planning before coding is the highest-leverage prompt of the five. It locks scope so the later prompts don’t sprawl.

Key MVP decision: ship AC + PY/PL/BU with Δ and Δ% tiers, semantic colors, two orientations. Push FC notation, axis break, small multiples, drill, and theme-JSON import to Phase 2.

Prompt 2 — Scaffold the two visuals + a shared core

“Scaffold ibcsMultiTierColumn and ibcsMultiTierBar as pbiviz projects plus a shared TypeScript module for the variance math, wired via a tsconfig @shared/* path alias.”

The two visuals differ only in axis orientation, so the agent factored the variance calculations, scenario styling, and types into a shared/ module consumed by both. One core, two thin orientation wrappers. This is exactly the kind of boring-but-correct structure an agent gets right when you ask for it explicitly.

Prompt 3 — Implement the integrated variance chart

“Implement the v0.1 integrated variance layout: three tiers on a shared category axis — base (AC overlaid with the reference), absolute Δ, and Δ% — for both orientations.”

This is the headline feature. The agent rendered the three-tier layout, computed Δ and Δ% per category, and overlaid the reference bar on the actual. First working draft of both the column and the bar variant.

Prompt 4 — IBCS notation & correctness polish

“Apply IBCS conventions: AC solid black, PY outlined, PL/BU hatched; semantic green/red variance; per-tier independent scales; share the base-tier pixels-per-unit with the absolute-Δ tier so the Δ bars are visually honest; add a scrollbar when categories exceed the viewport.”

This was the longest stretch — the difference between “a chart” and “an IBCS chart.” Highlights:

  • Share base-tier scaling with the absolute-Δ tier (IBCS-correct magnitude).
  • Pin/needle style for the Δ% tier.
  • Clamp labels inside tier bounds so AC labels never overlap variance values.
  • Deterministic sorting (never trust input order), default sort = actual descending.
  • Scroll behavior: vertical-only for bar, horizontal-only for column, with reserved scrollbar width so the layout doesn’t jump.

Lesson: the agent nails the 80% layout fast, but the IBCS correctness details (honest scaling, label collisions, notation) need you to know what “right” looks like and prompt for it specifically.

Prompt 5 — Format pane, versioning & packaging

“Add format-pane options (text font/size/color, per-measure decimal places, outlier cutoff, an About card showing the version), auto-bump the 4th version segment on every package, and produce a distributable .pbiviz.”

The finishing layer that makes it feel like a product: configurable formatting, an auto-injected About card, a version bump on every package, and signed .pbiviz files copied to releases/. End state: ibcsMultiTierColumn and ibcsMultiTierBar, both importable into any report.

What you actually get

Two visuals ibcsMultiTierColumn (vertical), ibcsMultiTierBar (horizontal)
Comparison AC vs PY / PL / BU
Tiers Base (AC + reference) · absolute Δ · relative Δ%
Notation AC solid · PY outlined · PL/BU hatched (FC dotted = Phase 2)
Color Semantic green/positive, red/negative; invert for cost measures
Formatting Font controls, per-measure decimals, outlier cutoff, About card
Tests Pure-TS variance math unit-tested; three-layer self-test strategy

The honest takeaways

  1. Plan first, code second. Prompt 1 (the plan + a capability map researched against the commercial IBCS visuals) shaped every later prompt and stopped scope creep.
  2. Architecture is a prompt. Asking explicitly for a shared core + thin wrappers gave clean, DRY code instead of two copy-pasted visuals.
  3. Domain knowledge is non-negotiable. The agent built a chart easily; turning it into an IBCS-correct chart required me to know honest scaling, scenario notation, and label rules and to prompt for them.
  4. “5 prompts” ≠ “no work.” Each prompt was a review-and-iterate loop. The agent did the typing; I did the judging.
  5. The output is inspectable. Unlike a black-box commercial visual, every line — variance math, scaling, notation — is in the repo and hackable.

And it took under an hour

That’s the part worth sitting with. Two IBCS-compliant custom visuals — ibcsMultiTierColumn and ibcsMultiTierBar — from a blank folder to packaged, importable .pbiviz files, in less than 60 minutes of guided prompting.

Not because the agent is magic, but because the loop — plan, scaffold, implement, review, correct — is fast when you bring the domain knowledge and let the agent do the typing. If an hour gets you two working visuals, picture what a focused day, or a week, actually unlocks: the FC notation, axis break, small multiples, drill-down, and theme-JSON import already scoped in Phase 2 — and well beyond.

Try it

Cheapest way to use Power BI - about 4 dollars per user per month with the Intelligence sheet

Power BI for $5 a Person — The Setup I’d Never Recommend (But It Works)

The cheapest way to use Power BI - about $5 per user per month with the Intelligence sheet and IBCS visuals

Everyone asks me how to make Power BI more powerful. Almost nobody asks how to make it cheaper. So let’s do the question nobody puts in a deck: what is the absolute cheapest way to use Power BI?

Short answer: replace your classic reports with the Intelligence Sheet in Microsoft Fabric Plan (built by Lumel) and dress it up with IBCS visuals. Done right, a read-only consumer costs you about $5 per person per month.

Now the honest part: I would not recommend the intelligence sheet as a long-term replacement for Power BI reports, but it is for sure a cost-effective alternative at least in the short run. If a customer is under real cost pressure and wants the cheapest thing that still delivers governed insight — at least temporarily — this is the way to go.

The setup is genuinely three steps

  1. Buy a Fabric capacity.
  2. Assign it to a workspace.
  3. Share the workspace with your users.

That’s it. No license tiers to plan, no agonising over who’s an “editor” and who’s a “viewer.” Fabric Plan meters each person automatically based on what they actually do. Someone only reads? They’re billed as a Viewer. The moment they type a number or build something, the meter reflects it. You stop managing licenses and start paying for activity.

The cost math (this is the fun part)

👉 Run your own numbers first. Before you trust any figure below, plug your headcount and capacity mix into the Fabric Plan pricing calculator at fabricplanning.io — the fastest way to sanity-check the per-person math for your region and audience.

Fabric Plan uses activity-based pricing — capacity units (CU) consumed, not named users licensed. Here’s the average sustained CU per active user:

Persona Triggered by ~Avg CU (sustained)
Viewer Read-only interaction ~0.05 CU
Stakeholder Data entry / approval ~0.23 CU
Planner Authoring / admin ~1.16 CU

Let’s price a realistic, mostly-read-only audience — exactly the crowd that today sits on a classic Power BI report:

  • 498 Viewers + 1 Stakeholder + 1 Planner = ~500 active users → ~26.3 CU of Plan activity.
  • That comfortably fits an F32 (32 CU), whose reservation is about $2,501/month (Central US).

One Pro license: optional, but I’d strongly recommend it

Intelligence sheets can sit on top of almost anything — a static CSV or Excel file, or a Fabric Warehouse. But the version you actually want is one built on a proper Power BI semantic model: governed measures, relationships, a single source of truth. For that, exactly one author needs a Power BI Pro license to create and publish the semantic model. That’s it — one license. Every viewer still consumes the model’s data without a Pro license of their own. So Pro is technically optional (you can run on static files or a warehouse), but for a setup you’d actually trust, it’s the one upgrade I’d insist on.

Don’t forget the Fabric resource overhead

That ~26.3 CU is only the Plan activity. Basing the sheets on a semantic model means the capacity also pays for Fabric resource consumption — XMLA reads from the Power BI semantic model, plus Fabric SQL and OneLake. Budget roughly 20% on top: 26.3 CU × 1.2 ≈ 31.5 CU, which still slots inside an F32’s 32 CU. That 20% buffer is exactly why I capped the audience at ~500 consumers rather than cramming in more.

Add it all up — the F32 capacity plus one Pro license for the author, divided across ~500 consumers:

($2,501 F32 + $14 Pro) ÷ 500 users ≈ $5 per person / month

Five dollars a head to put a governed, semantic-model-backed Intelligence sheet in front of a report consumer. That’s the floor.

Treat this as a planning estimate. The 20% Fabric resource overhead (XMLA reads, Fabric SQL, OneLake) is a rule of thumb — depending on model size, refresh patterns and query volume it can be meaningfully more or less, which changes how many consumers an F32 absorbs and therefore the exact per-head cost.

How does that compare to Power BI Pro?

A classic Power BI consumer needs a Pro license at $14/user/month (list price, since April 2025). So:

Option Cost per consumer / month
Power BI Pro (per-user license) ~$14
Intelligence sheet (F32, ~500 users) ~$5

Roughly two-thirds off per consumer. Which is exactly the kind of number that makes a CFO lean forward.

Important disclaimer — an F64 can be cheaper. The comparison above assumes per-user Pro licensing. But a Fabric F64 capacity unlocks free Power BI consumption — consumers with a free license can view content in an F64+ workspace, no Pro license required. A single F64 reservation runs about $5,003/month, so above roughly 360 consumers ($5,003 ÷ $14) plain Power BI on an F64 beats both per-user Pro and the per-user Intelligence math. Always run the numbers for your actual headcount before you commit.

Why I still wouldn’t seriously recommend it

Cheap is cheap because it gives things up. Be honest with yourself about the trade:

  • Intelligence sheets aren’t Power BI reports. As a Power BI fan, I’ll miss some of what a real report brings — the Office integration and the familiar authoring flow in Power BI Desktop. Here you build in the Fabric Plan experience instead, which is a different way of working.
  • Mobile is limited. There isn’t a dedicated mobile experience the way a Power BI report offers one.

Use it when budget pressure is real, the scope is contained, and there’s a genuine plan to revisit. Avoid it when you’re building a platform meant to scale across an organisation.

The takeaway

The cheapest way to put governed, well-designed insight in front of report consumers is the Intelligence sheet plus IBCS, at about five dollars a head. Think of it as a lifeboat rather than your forever-architecture — but if budget pressure is real, now you know it exists, and you know the number.

Numbers are list-price planning estimates. Fabric Plan pricing per Lumel; Power BI Pro pricing and F64 free-consumption per Microsoft Learn. CU rates are region-uniform; dollar cost per CU varies by region.

Watch: the live session

The Quiet Superpower of Microsoft Analytics Pricing: It Does not Keep Going Up

⚠ Disclaimer: This is my personal opinion – not Microsoft’s official positioning, not a pricing commitment, and not a statement on behalf of the Power BI or Fabric teams. All numbers come from public pricing pages at the time of writing (June 2026) and can change at any time. Crucially, I have no insider knowledge about future pricing – no information about upcoming increases, discounts, or pricing-policy changes for Power BI or Microsoft Fabric, and equally no information that prices will never change. Nobody should read this as a promise. Over a long enough horizon, some price increase is realistically inevitable – that is true for every vendor. Read this as one enthusiast’s perspective, not product guidance.

TL;DR:

  • Enterprise capacity pricing has never gone up. Power BI Premium P SKUs (2017) and Microsoft Fabric F SKUs (2023) – P1, F64 and friends – have never had a per-capacity price increase.
  • One exception in a decade: a single, first-ever bump on the per-user licenses (Pro and Premium Per User), effective 1 April 2025.
  • Competitors raise list prices far more often – routinely, sometimes annually.
  • You get more for the same money over time. Fabric introduced small capacities (from F2 upwards), and premium features keep moving down the SKU ladder – e.g. Fabric Copilot, once an F64 privilege, is now available from F2.
  • My read: the per-user adjustment arguably makes Fabric capacity look even more attractive – exactly where Microsoft has been steering customers anyway.

The headline: enterprise pricing has been remarkably stable

Let me be precise, because precision is the whole point. Power BI Premium capacity (P SKUs) launched in 2017. From launch through its transition, the monthly price of P1 did not increase – not once. Microsoft Fabric capacity (F SKUs) arrived in 2023, and since then the published per-capacity rates – including the workhorse F64 – have not been hiked either.

So if your organisation runs analytics the way most enterprises do – on a dedicated capacity rather than counting individual seats – your unit price for the underlying platform has been flat for years. In a market where an “annual list-price adjustment” is practically a calendar event for some vendors, that stability is worth calling out.

In fact, it is so stable it makes for one of the most boring charts I have ever drawn. Behold:

Price for Capacity – a flat line at $5,000 from 2017 to 2026
A decade of riveting price action. The line is doing exactly what enterprise customers love most: nothing.

What about that F64 number on the pricing page?

A clarification I get asked about constantly. On the Azure pricing page an F64 (USD, cheaper US regions such as East US / Central US) shows roughly:

  • Pay-as-you-go: ~$8,409.60 / month
  • 1-year reservation (~41% off): ~$5,002.67 / month

That $5,002.67 is the reserved (cheapest) rate – it is not a price increase, just an hourly meter expressed monthly. The reservation column is the discount; there is no hidden tier below it. (And no, there is no “€2,994 F64” – that is an F32-sized number.)

The one exception: a single per-user adjustment

Credit where it is due – let us not pretend nothing ever changed. In late 2024 Microsoft announced the first-ever increase for the per-user Power BI licenses, effective 1 April 2025:

License Before After
Power BI Pro $9.99 / user / month $14 / user / month
Power BI Premium Per User (PPU) $20 / user / month $24 / user / month

Pro had held at $9.99 since 2015 – almost a decade without a change. Even after the adjustment it remains modest compared with per-seat pricing elsewhere in the category.

Reframing the per-user increase: a nudge toward capacity?

Here is where I offer an opinion (again: mine, not Microsoft’s). The economics of analytics platforms reward consolidation. As your user count grows, per-seat licensing scales linearly, while a capacity – a fixed monthly cost serving everyone who reads content – scales far better. There is a crossover point where moving from “lots of Pro seats” to “one Fabric capacity” simply costs less per head.

By nudging the per-user price up while keeping capacity prices flat, the relative maths shifts: capacity becomes more attractive, sooner. And capacity is exactly where Microsoft has been guiding customers – Fabric F SKUs are the strategic destination, with F64 as the threshold that unlocks free content consumption for viewers (no Pro seat required to read reports).

So you can read the 2025 per-user adjustment two ways, and I think both are true at once:

  1. A normal, overdue catch-up after ten flat years on Pro.
  2. A gentle economic signal that the future is capacity-based Fabric, not seat-counting.

Either way, the part of your bill that powers the platform itself – the capacity – did not move.

And here is the part that often gets missed: you get more for the same money

Flat pricing would already be remarkable. But the story is actually better than “the price held” – because what you get for that price has steadily expanded.

Smaller capacities arrived. In the Power BI Premium era, the entry point into capacity was effectively P1 – the equivalent of an F64. That was a serious commitment, and it priced a lot of smaller teams out of capacity entirely. Microsoft Fabric changed that by introducing small capacities: you can now start at F2 and step up through F4, F8, F16, F32 long before you ever reach F64. Capacity is no longer an all-or-nothing “F64 or bust” decision – it scales with you, from a couple of hundred dollars a month upwards.

Premium features keep moving down the ladder. The most telling example is Fabric Copilot. At launch, Copilot required an F64 (or P1-equivalent) capacity – a genuinely high bar. That threshold has since been lowered: Copilot is now available from F2. So a capability that used to demand a ~$5,000/month commitment is now reachable on an entry-level SKU costing a fraction of that. The headline price of F64 did not change – but the price of access to its marquee AI feature dropped dramatically.

And look at how much more the platform does now. Think back to what a Power BI Premium capacity actually was: a reporting and BI engine. The same capacity today – at the same price – also gives you a full data engineering stack (Spark, notebooks, Lakehouse), data warehousing, data science, real-time intelligence, Data Factory-style pipelines, databases, OneLake as a unified data lake, and planning capabilities. It is genuinely a bit crazy how many workloads have been folded into the same capacity over a couple of years – entire product categories that used to be separate purchases are now just “another workload” on the SKU you already own.

Am I naive about why? Of course not. Every one of those workloads is also designed to consume more of your capacity – the more you do on Fabric, the more CUs you burn, and the sooner you size up. That is the commercial logic, and it is fair to name it. But here is the key distinction: that is consumption growth, not a price increase. The per-CU, per-SKU price did not go up. You are simply able to do far more with the capacity you already pay for – and you stay in control of how much you actually use.

Put those together and the effective value trend is the opposite of a price increase: same flat capacity prices, smaller entry points, premium features unlocking at lower tiers, and a pile of new workloads on the same SKU. You are getting more capability per dollar each year, not less.

Meanwhile, across the street

I am not going to call out specific competitors by name or quote their numbers – partly to stay fair, partly because those numbers change so often that any figure I print here would be wrong within a year or two. But it is no secret that across the broader BI and cloud-data-platform landscape, list-price increases are a routine, recurring event for several well-known vendors – sometimes annually, sometimes tied to “platform modernisation,” sometimes via repackaging that quietly raises the effective rate.

Against that backdrop, a single per-user adjustment in ten years, with enterprise capacity pricing untouched, is a genuinely different posture.

So what should you actually do?

  • If you are seat-heavy: model the crossover. Past a certain number of viewers, an F64 (or right-sized F SKU) often beats stacking Pro licenses – and free viewer consumption at F64+ is a big lever.
  • If you are already on capacity: your platform unit cost has been stable. Use a 1-year (or 3-year) reservation for the ~41% discount over pay-as-you-go.
  • Plan for change anyway: build your business case so it survives a future adjustment. Stability so far is not a guarantee forever – budget with a sensible buffer.

Bottom line

For enterprise, capacity-based analytics on Microsoft, the price of the engine – P1 yesterday, F64 today – has not gone up. If anything, you get more: small capacities from F2 now exist where P1/F64 was once the only door in, and premium features like Fabric Copilot have moved down from F64 to F2. The lone exception is a single, first-in-a-decade bump on per-user Pro/PPU, which arguably makes Fabric capacity look even better by comparison.

I do not know what the future holds on pricing, and neither does anyone outside the teams who set it. Eventually, something will probably change. But as of today, the story is simple and, frankly, unusual in this industry: the enterprise price held.

Figures verified against public pricing pages in June 2026 and subject to change – always check the official Microsoft Fabric pricing page and Power BI pricing page.

The Future Is Vibecoding: Why I’d Pick Rayfin Over Power Apps Every Time

⚠ Disclaimer: This is my personal opinion and a deliberately bold, provocative take – not Microsoft’s official positioning, and not a statement on behalf of the Power Platform or Fabric teams. Rayfin is an early, evolving product; Power Apps remains the right choice for many scenarios. Read this as one enthusiast’s perspective, not product guidance.
Rayfin apps in Microsoft Fabric

TL;DR – why Rayfin is the clear successor to Power Apps:

  • Vibecoding is the future. You describe the app in plain language; GitHub Copilot writes the code. Hand-coding is on its way out.
  • You don’t need to be a developer. I can’t write a line of TypeScript – yet I shipped a live, authenticated app into Fabric in minutes.
  • Safe by design. Your app is locked inside your Fabric ecosystem: Entra identity, workspace governance, data in your own tenant.
  • No per-seat tax. It runs on the Fabric capacity you already own – and hosting plus authentication are free.
  • No ceiling, no lock-in. You get real, owned, portable code instead of a proprietary canvas artifact you can never export.
  • The only open question isn’t if you’ll move off Power Apps – it’s when.

Let me say the quiet part out loud: the future is vibecoding. Soon, no one will write code by hand.

Not “fewer people.” Not “vibecoding only for prototypes.” No one. And to be clear: this isn’t vibecoding only for prototypes — it’s vibecoding for the real, production app you actually ship. You’ll describe what you want in plain language, an agent will write the code, and you’ll ship it. The keyboard-warrior phase of software – memorising syntax, fighting a proprietary formula language, googling error messages at midnight – is ending. And the funny thing is, the people who’ll benefit most aren’t developers at all. They’re the rest of us.

I know, because I’m one of them.

I can’t write a single line of TypeScript – and I shipped anyway

Here’s my confession as a data platform person: I am not a developer. I cannot write a single line of TypeScript, React, or anything that compiles. And yet, a couple days ago, I published a real, authenticated, data-backed web application into Microsoft Fabric – with nothing but GitHub Copilot and an idea. Minutes. Not hours. Not days.

That app was the IBCS Trainer – a little Jump & Run game that teaches IBCS rules by stomping on bad charts. Behind the silly premise sits something serious: it runs as a Rayfin app inside Fabric, it signs users in with their Entra identity, and it writes every play-through into a typed database that I can query with plain SQL afterwards. I didn’t stand up a database. I didn’t configure an App Service. I didn’t open a single infrastructure ticket. I described what I wanted, Copilot wrote it, and one command put it live next to my lakehouse. And a couple of minutes later I had three additional sample Rayfin apps from awesome Rayfin deployed.

If you’d told me a year ago that the non-coder in the room would ship a governed app faster than a Power Apps specialist could wire up a canvas – I’d have laughed. Today it’s completely normal.

So what is a Rayfin app?

Rayfin is a backend-as-a-service that lives inside Microsoft Fabric. You write a front-end (or let Copilot write it for you), and Rayfin provisions everything behind it: a real SQL database in Fabric, a typed data API, authentication, and static hosting – all as a Fabric item. One command, rayfin up, builds it and hands you a live URL.

How a Fabric app fits together

The part that matters for people like me:

  • Your app lives where your data lives. Fabric stops being “just reports and pipelines” and becomes a place you can host the things people actually click on.
  • Governance comes for free. The app inherits your Fabric workspace permissions and Entra identity. Your IT and security teams already know how to govern it – there’s nothing new to approve.
  • It’s genuinely fast to ship. Idea to authenticated, live, governed app in a single deploy command.

That’s the whole pitch, and it holds up.

Vibecoding beats learning the Power Apps UI

Now the spicy bit. People will say: “But Power Apps is for non-developers. Vibecoding still needs a coder.”

That’s backwards. Learning Power Apps is learning to code – just in a worse, proprietary language that’s useless everywhere else. You still have to master Power Fx formulas, delegation limits, connector quirks, the canvas property model, environments and solution layers. That’s a steep, single-vendor skill tree, and the moment you hit its ceiling, you’re stuck.

Vibecoding asks me to do the one thing I already do effortlessly: describe what I want.

Creating a Fabric app the easy way

“Build me a form to log site inspections with a photo and a date, and show me last week’s entries.” That sentence is easier than building the same thing on a canvas – no formulas, no delegation warnings, no connector configuration. The agent writes the code; I review the working result. And when I want to change it, I don’t go re-learn where a property hid in some designer two years ago. I just say: “add a status column and a filter for open items.” Maintenance is a conversation, not a re-certification.

Best of all, the skill I’m building – describing software – transfers everywhere. The hours someone spends mastering Power Fx buy them nothing outside Power Platform. That’s a dead-end investment in a world that’s moving to language as the interface.

Your app is locked safely in your Fabric ecosystem

Here’s the line that makes security teams relax instead of panic: your vibecoded application is fully safe, because it’s locked safely inside your Fabric ecosystem.

This isn’t a random web app deployed to who-knows-where. A Rayfin app is a Fabric item. That means:

  • Identity is Entra, brokered by Fabric. Sign-in and sessions are handled by the platform, not by some hand-rolled auth you have to trust.
  • Access is workspace permissions. The same governance model that protects your lakehouses and semantic models protects your app. No new perimeter, no shadow IT.
  • The data stays in Fabric. Every write lands in a real Fabric SQL database in your tenant, under your capacity, inside your compliance boundary – queryable for Power BI like everything else you own.

So when a non-developer ships an app this way, it isn’t a liability hiding in a corner. It’s a first-class, governed citizen of your data estate. That’s the opposite of the classic low-code sprawl problem.

But what does it actually cost?

Fair question – and the answer is refreshingly boring, which is exactly what you want.

A Rayfin app runs on the Fabric capacity you already have. There’s no per-user license, no per-app license, no premium-connector tax. It simply draws Capacity Units (CUs) from your workspace, and you watch it in the Fabric Capacity Metrics app like any other workload. (Full pricing details on Microsoft Learn.)

Only three things consume capacity:

  • SQL Database – compute for every query and write, plus storage for your tables. (For the nerds: one Fabric CU equals 0.383 SQL database vCores.)
  • GraphQL API – the typed data layer your app calls. Billed at ten CUs per hour of request-and-response processing time – so you pay for actual usage, not for it sitting idle.
  • OneLake storage – your built front-end (HTML, CSS, JS) when static hosting is on, plus the read/write operations to serve it.

And here’s the part Power Apps can’t match – what’s free:

  • The app hosting service – API routing and the application backend. No charge.
  • Authentication – Entra SSO sign-in and session management. No charge.
  • Deployment – running rayfin up itself costs nothing beyond the storage operations it triggers.

Read that again: hosting and authentication – the two things you’d normally pay a platform tax for – are included. If you already run Fabric, your app essentially rides along on capacity you’ve already bought. Compare that to stacking per-user Power Apps licenses on top of everything else, and the math gets uncomfortable for the incumbent very quickly.

When will you switch your Power Apps to Rayfin?

Here’s the whole argument on a single screen:

Power Apps Rayfin in Fabric
How you build Learn Power Fx + the canvas designer Describe it; Copilot writes the code
Who can build A trained maker Anyone who can describe an app
Where it lives A separate Power Platform environment A Fabric item, right next to your data
Identity & governance Separate environment and DLP setup Entra + Fabric workspace permissions, built in
Pricing Per-user / per-app licenses Fabric capacity you already own — hosting + auth free
The code Opaque, locked to the platform Real, owned, portable code
Ceiling Hit the wall and you’re stuck Drop into the code — no ceiling

So I’ll leave you with the question I keep asking colleagues: which of your apps no longer needs a canvas?

Because the trade-off that justified low-code is gone. You no longer give up control to get speed – vibecoding gives you both. You get real, owned, portable code instead of an opaque artifact. You get Fabric-grade governance instead of low-code sprawl. You get capacity-based pricing instead of a per-seat tax. And you get all of it without writing a line of code yourself.

I’m a reporting person who can’t code, and I shipped a governed app into Fabric in minutes. If I can do that, your next internal tool, data-entry front-end, or little team app doesn’t belong on a canvas anymore.

The future is vibecoding. The only question is which of your apps you’ll build differently from here on.

If you’re building on Fabric, take Rayfin for a spin. And if you want to see what a non-developer can actually ship with it, go stomp some pie charts in the IBCS Trainer – that whole game is a Rayfin app.

Learn IBCS by Playing: A Jump & Run Rayfin App in Fabric

Let’s be honest: IBCS rules are not exactly a page-turner. “Use solid fill for actuals, outlined for plan, hatched for forecast, light grey for previous year.” It’s the right way to build reports — but reading a 200-page standard is how you lose an audience in the first five minutes.

So I tried something different. The idea came from Tim Ebner: what if you could gamify learning the IBCS rules instead of memorising them? Credit where it’s due — that one suggestion is what turned a dry standard into the little game below.

Meet the IBCS Trainer

The IBCS Trainer is a little browser platformer — think Super Mario, but every enemy is a badly-designed chart and every coin is a chart done the IBCS way. You run, you jump, and you learn the SUCCESS rules one level at a time without ever opening a PDF.

Go on — have a go right here. Click the game, then use the arrow keys to move and jump:

If the embed does not load, open the game directly: https://kornalexander.github.io/ibcs-trainer/

The core loop is dead simple:

  • Stomp the bad charts. Pie charts, rainbow-coloured bars, axis breaks, giant “big number” tiles — they walk toward you as enemies. Jump on them and they explode.
  • Collect the good charts. The correct IBCS notation walks across the level as a collectible. Grab it for points.

By the time you’ve cleared a level, your hands already “know” the rule — because you spent two minutes acting it out instead of reading about it.

One rule per level

Each level teaches exactly one idea, in roughly the order you’d actually learn IBCS:

  • Pie vs. column. Pies explode; columns and lines are what you collect. Time series belong in columns and lines, not slices.
  • Solid = actual, outlined = plan, hatched = forecast, light grey = previous year. The notation that lets anyone read a chart in any language.
  • Show the deviation, not just the big number. A huge headline figure is the enemy; the variance bar is the prize.
  • MECE. Overlapping, double-counted categories get stomped; clean, mutually-exclusive structures get collected.
  • Simplify. Chart junk, gridlines and decoration are the bad guys. Clean beats clever.
  • No axis breaks. Truncated axes lie — so they’re enemies too.

There’s a small twist for the IBCS purists reading this: the hero isn’t a plumber, it’s a data analyst, and the levels are themed around real charting decisions you make every single day.

Why bother gamifying it?

This was Tim Ebner’s idea, and it holds up for two reasons. First, retention. People remember what they did, not what they read. Stomping a pie chart is a far stickier memory than the sentence “avoid pie charts for time series.”

Second, reach. A game is something you can hand to a colleague who has never heard the word IBCS, and they’ll absorb half the standard before they even realise they’re being trained. That’s a much easier sell than a workshop invite.

The quietly big part: Rayfin Apps in Fabric

Here’s the bit that genuinely got me excited as a data platform person. The whole game runs as a Rayfin app hosted inside Microsoft Fabric.

If you haven’t come across Rayfin yet: it’s a backend-as-a-service that lets you ship a real, interactive web app — authentication, a typed data layer, static hosting — directly as a Fabric item. One command (rayfin up) builds it, automatically provisions a full backend — including a database in Fabric — wires up Entra/Fabric auth, and gives you a live URL. No separate App Service, no standalone database to babysit, no infrastructure ticket. You write the app; Rayfin stands up everything behind it.

Why is that a big deal?

  • Apps live where your data lives. Fabric stops being “just reports and pipelines” and becomes a place you can host actual applications next to your lakehouse and semantic models.
  • Governance comes for free. The app inherits Fabric workspace permissions and Entra identity. Your IT and security teams already know how to govern it.
  • It’s genuinely fast to ship. The IBCS Trainer went from “single HTML file” to “authenticated app live in a Fabric workspace, persisting every play-through to a typed entity” in a single deploy command.

That last bit deserves a moment. Because Rayfin provisions the backend for you, every game stat is saved automatically into a database in Fabric — your score, the level you reached, deaths, charts collected, how long you played, the lot. When you hit game-over, the app writes the whole run to a typed GameStats entity in the background. No copy-paste, no manual save step.

And because it lands in a real Fabric database, the data is trivially queryable afterwards. Since each run is tied to the signed-in Entra identity, I can answer questions like which users played, how often, and for how long with a single SQL query — no extra plumbing. What started as a teaching game is suddenly a fully tracked usage dataset sitting right next to the rest of my Fabric estate, ready for a Power BI report.

If you’ve read my earlier Jump & Run post, that’s the part that finally clicked. There, saving a score meant copying JSON out of the game and pasting it into a notebook cell by hand — because Fabric’s sandboxed displayHTML() iframe blocks everything. With Rayfin, the app is the backend: the JavaScript just calls the typed data layer directly, and the playthrough lands in storage. The thing I was hacking around for months became a non-issue.

For me that last point is the headline. Fabric is increasingly not just where you analyse data — it’s where you can build and host the things people actually click on. A teaching game is a fun first example, but the same pattern works for internal tools, data-entry front-ends, and lightweight apps that used to need a whole separate stack.

One thing on my wish list: I’d love Rayfin to support metadata write-back to semantic models and Power BI reports. Imagine a little Rayfin app that lets a steward edit measure descriptions, fix display folders, or tweak report metadata, and writes those changes straight back into the model or report definition. Today that isn’t supported — Rayfin gives you a database and an app, but not a write path into semantic-model or report metadata. If that ever lands, the line between “lightweight app” and “governed authoring tool” gets very blurry, in the best way.

Try it

The IBCS Trainer is a small, slightly silly project with a serious goal: make best-practice reporting muscle memory instead of homework. If you’ve ever struggled to get a team to care about chart standards, handing them a game beats handing them a style guide.

And if you’re building on Fabric, take Rayfin for a spin. The gap between “I have an idea for an app” and “it’s live and governed in my tenant” just got a lot smaller.

Bringing the PowerLib IBCS Templates Together into One Report

A quick note on credit

First things first: none of the visuals you see below are mine. Every single chart, pattern, and design idea comes from PowerLib — the brilliant series of IBCS-standard Power BI templates published by PowerLib (hello.powerlib@gmail.com). If you don’t already follow their work, go do that now. Each template (the FA0xx series) is a self-contained lesson in how to apply the International Business Communication Standards (IBCS) in Power BI.

All I did was combine the individual templates into a single report — one semantic model, one report file, 51 pages. That’s it. The craft, the DAX, the IBCS thinking — that’s all PowerLib.

Why combine them at all?

PowerLib ships each technique as its own file, and honestly that is the better way to learn. Each standalone template is focused, clean, and easy to study one concept at a time — actual-vs-target, waterfalls, tornado charts, scatter storytelling, and so on. If you want to understand a pattern, open the original individual file.

So why merge? One reason: sharing.

  • One file is dramatically easier to hand to a colleague, drop in a Teams chat, or open at a customer.
  • No juggling 28 separate files and 28 separate datasets.
  • A single “best-of” report makes a great demo and reference deck you can flip through in one session.

Individual files = more perfect for learning.
One combined report = easier for sharing.

Pick the one that fits what you’re doing.

A best-of tour

Here are a few of my favourite pages from the combined report — all originally designed by PowerLib:

Several Ways to Visualize Actual vs. Target

Several Ways to Visualize Actual vs. Target

Dynamic Data Storytelling Using Scatterplots

Dynamic Data Storytelling Using Scatterplots

Integrating Slope Graphs into Line Charts

Integrating Slope Graphs into Line Charts

Columns with Waterfall Charts

Columns with Waterfall Charts

Creating Dynamic IBCS-Standard Pie Charts

Creating Dynamic IBCS-Standard Pie Charts

Visualizing Variances with Error Bars Dynamically

Visualizing Variances with Error Bars Dynamically

Building a Tornado (Butterfly) Chart

Building a Tornado (Butterfly) Chart

Visualizing Surplus & Deficit in a Stacked Column Chart

Visualizing Surplus & Deficit in a Stacked Column Chart

Get the combined report

I put the merged PBIP (report + semantic model + data) on GitHub so it’s easy to clone and open in Power BI Desktop: https://github.com/KornAlexander/powerlib-ibcs-report. If you just want to flip through all the patterns in one place, this is the fastest way in.

Credits

  • Original templates, designs and IBCS implementation: PowerLib (hello.powerlib@gmail.com)
  • Merge into a single report: Alexander Korn

If you found any of this useful, the credit belongs to PowerLib — please support their channels.

Custom Visuals Inventory for Fabric

Custom visuals are great — until they break, get deprecated, or you need to know which reports actually depend on them. I built a small Fabric notebook that gives you a tenant-wide answer in seconds.

Big thanks to Steinick Sibarani for the nudge that pushed me to put this together quickly — the conversation around custom-visual governance in his community thread was exactly the spark this needed.

The Microsoft community thread by Steinick Sibarani that triggered this notebook

What it does

Custom Visuals Inventory uses semantic-link-labs to list every custom visual used across one workspace, a list of workspaces, or your entire tenant. You get:

  • A flat table: workspace, report, visual name, visual GUID
  • Top visuals by report count (where is TRUECHART actually used?)
  • Heaviest reports by custom-visual count
  • A PBIR-format inventory (PBIR vs. PBIRLegacy) — because only PBIR reports can be scanned

One MODE switch flips between current, list, and all workspaces. That’s it.

Notebook on GitHub: PBI-Tools / Notebook Gallery · also published in the Fabric Community Notebook Gallery.

Why this matters for FUAM

FUAM is the go-to solution for tenant-wide Fabric monitoring — workspaces, capacities, activities, refreshables, git connections, tenant settings. But there is one thing it does not ship today: a custom visuals inventory per report.

This notebook fills the gap as a standalone companion — same scope (tenant-wide), same stack (Fabric notebook + Direct Lake friendly output).

If you run a Fabric tenant with more than a handful of reports, this is one notebook you want in your back pocket the next time a custom visual gets deprecated.

Unlimited Power BI Usage History — Snapshot the Built-In Usage Metrics Model to Lakehouse

Power BI’s built-in usage metrics report is great — until you need history beyond 30 days. The underlying dataset is a rolling window: yesterday’s view counts are there, last quarter’s are gone. If you want to track adoption trends, prove ROI, or spot reports that have quietly died, you need to capture that data yourself.

The fix is surprisingly simple: a single Fabric notebook that queries the hidden Report Usage Metrics Model semantic model over XMLA and appends each daily snapshot to Lakehouse Delta tables. Unlimited history, append-only, ~30 lines of Python.

Usage Metrics Snapshot architecture

Honest Disclaimer — Prefer FUAM

Before you build this: if you have any meaningful scale of Power BI / Fabric tenant, use FUAM (Fabric Unified Admin Monitoring) instead. FUAM is the Microsoft-published, open-source accelerator that snapshots not just usage metrics but capacity events, activity logs, refresh history, inventories — the whole tenant story — into a Lakehouse with a ready-made semantic model and report. It is far more complete than what’s in this post.

So when do I reach for the little notebook below instead?

  • A single workspace where you just need report-level view history and don’t want to deploy a full monitoring solution.
  • You need a quick fix today and FUAM rollout is weeks away.
  • You want to understand how the underlying mechanism works — the notebook is small enough to read end-to-end in five minutes.

For everything else: start with FUAM.

The Problem: 30 Days Is Not Enough

  • Rolling window. Each day, the oldest day falls off. Anything older than 30 days is permanently gone — you cannot recover it.
  • No YoY, no trends. Did adoption grow over the last year? Which reports are losing users? You literally cannot answer these questions with the built-in model.
  • No ownership. Microsoft controls the model. Schema changes happen without notice. You cannot extend it, share it, or join it to your own dimensions cleanly.

The Solution: Daily Snapshot to Lakehouse

The hidden Report Usage Metrics Model is a normal semantic model — it just happens to be auto-managed by Microsoft. That means you can hit it with XMLA queries like any other model. Using sempy.fabric.evaluate_dax, we pull each source table, stamp a SnapshotUtc column, and append to Delta tables in a Lakehouse:

import sempy.fabric as fabric
from datetime import datetime, timezone

WORKSPACE_ID = "<your-workspace-guid>"
DATASET_NAME = "Report Usage Metrics Model"
TABLES = ["Views", "Reports", "Users", "Dates", "DistributionMethods", "Platforms"]

snap_ts = datetime.now(timezone.utc)

for t in TABLES:
    df = fabric.evaluate_dax(
        dataset=DATASET_NAME,
        workspace=WORKSPACE_ID,
        dax_string=f"EVALUATE '{t}'",
    )
    df.columns = [c.split("[")[-1].rstrip("]") if "[" in c else c for c in df.columns]
    df["SnapshotUtc"] = snap_ts.isoformat()
    (spark.createDataFrame(df).write
        .mode("append")
        .option("mergeSchema", "true")
        .saveAsTable(f"usage_metrics_{t.lower()}"))

That’s the whole engine. Schedule it daily after 04:00 UTC (the source refreshes around 03:00 UTC) and you have a permanent historical record.

What Lands in the Lakehouse

One Delta table per source table, prefixed usage_metrics_*, with an extra SnapshotUtc column. Append-only — every run adds today’s full snapshot.

Source tableLakehouse tableRole
Viewsusage_metrics_viewsFact
Reportsusage_metrics_reportsDimension
Usersusage_metrics_usersDimension
Datesusage_metrics_datesDimension
DistributionMethodsusage_metrics_distributionmethodsDimension
Platformsusage_metrics_platformsDimension

Three Design Decisions Worth Calling Out

  • Append, not merge. Every snapshot is the full 30-day window. Yes, days overlap across snapshots — but storage is cheap and append is bulletproof. Deduplication happens at query time (see below), not at ingest time.
  • mergeSchema=true. Microsoft occasionally adds columns to the usage metrics model. With schema merging on, the next snapshot just absorbs the new columns instead of crashing.
  • Retention with DELETE. Default 400 days (≈13 months, enough for YoY) — but you can set RETENTION_DAYS = None to keep forever. The delete is a normal Delta operation, so time travel still works if you mess up.

Querying Without Double-Counting

Because every snapshot contains the last 30 days, the same activity row appears in up to 30 snapshots. To get clean numbers, take the latest snapshot per natural key:

WITH ranked AS (
    SELECT v.*,
           ROW_NUMBER() OVER (
               PARTITION BY Date, ReportGuid, UserGuid
               ORDER BY SnapshotUtc DESC
           ) AS rn
    FROM usage_metrics_views v
)
SELECT Date,
       ReportGuid,
       COUNT(*)                  AS views,
       COUNT(DISTINCT UserGuid)  AS distinct_users
FROM ranked
WHERE rn = 1
GROUP BY Date, ReportGuid
ORDER BY Date DESC, views DESC

For older history (where a date appears in only one snapshot), the deduplication is a no-op — the row simply passes through. For the most recent 30 days, you always pick the freshest version of each fact.

Prerequisites

  • Workspace on Premium / PPU / Fabric capacity (XMLA endpoint enabled — read is enough).
  • The Report Usage Metrics Model dataset exists in the workspace. It is auto-created the first time anyone clicks More options → View usage metrics report on any report in that workspace.
  • A Lakehouse attached to the notebook (any Lakehouse in the same workspace works).
  • Tenant setting “Usage metrics for content creators” enabled (admin portal).

Try It — Fabric Notebook Gallery

The notebook is also submitted to the Fabric Notebook Gallery. Grab the .ipynb directly from GitHub and import it into any Fabric workspace:

📓 Usage Metrics Snapshot.ipynb — one notebook, six Delta tables, daily schedule. Set WORKSPACE_ID, attach a Lakehouse, schedule after 04:00 UTC. Done.

Take It Further — A Power BI Report on Top

The Lakehouse tables are already the hard part. From here, building a proper Adoption & Usage Power BI report is a short hop:

  • Point a Direct Lake semantic model at the six usage_metrics_* Delta tables — no import, no refresh schedule, fresh on the next snapshot.
  • Wrap the "latest snapshot per natural key" dedup logic in a SQL view in the Lakehouse SQL endpoint so the model stays simple. One view per fact, deduped, ready to consume.
  • Build the obvious pages: Adoption over time (views & distinct users by month, YoY), Top & bottom reports, Dying reports (had >X views last year, <Y this quarter), Platform & distribution mix.
  • Join to your own Reports dim (owner, business domain, criticality) for actionable cuts — e.g. "critical reports with zero views in 30 days".

That’s the whole point of owning the history: once the data lives in your Lakehouse, you can model and visualise it however your stakeholders need — not however Microsoft’s built-in report happens to ship it.

Wrap-Up

One notebook, one daily schedule, six Delta tables — and the 30-day blind spot is gone. You own the history, you can join it to your own data, and you can build proper adoption dashboards on top.

The full notebook (with retention, health-check, and example query cells) is on GitHub: KornAlexander/PBI-Tools → Notebook Gallery / Usage Metrics Snapshot.ipynb.

The Semantic Layer Debate: BI-Tool-Centric (Microsoft Fabric) vs. Data-Platform-Centric

The Semantic Layer Debate: BI-Tool-Centric vs. Data-Platform-Centric

Why moving your semantic layer to a separate data platform might not be the obvious choice it seems.

In practice this is a vendor question too: BI-Tool-Centric means your metrics live in your BI platform — for most readers here, Microsoft Fabric / Power BI. Data-Platform-Centric means pushing them down into a separate data-engineering / lakehouse platform and letting BI tools consume from there.

Disclaimer: The opinions expressed in this post are my own and do not represent the views of my employer.

The Debate in 30 Seconds

The analytics industry is in a heated argument about where your business metrics should live:

  • Camp A (BI-Tool-Centric): Define your semantic model in your BI tool. It’s where your users already are. → e.g. the Microsoft Fabric / Power BI semantic model.
  • Camp B (Data-Platform-Centric): Define your semantic layer in the data platform. Let every downstream tool consume it. → e.g. a standalone data-engineering / lakehouse platform that sits below your BI tools.

Camp B has been gaining momentum across the industry. This post walks through seven dimensions to help you critically evaluate both approaches before making a strategic decision.

A Note on Terminology

These two terms are often used interchangeably, but they mean different things:

  • Semantic model — A concrete implementation: tables, relationships, measures, hierarchies, and business logic bundled into a queryable model. In Power BI, this is the semantic model (formerly “dataset”). It’s where your KPIs, time intelligence, and row-level security actually live.
  • Semantic layer — The broader architectural concept: an abstraction that maps business terms to underlying data so consumers don’t need to know table structures or write raw SQL. In Power BI, most often the semantic layer sits on top of one or more semantic models, but it can also incorporate other data sources — lakehouses, warehouses, APIs, or real-time streams.

Throughout this post, “semantic model” refers to the BI tool’s implementation, while “semantic layer” refers to the platform-level abstraction.

Practically, when this post says BI-Tool-Centric, picture a unified BI platform like Microsoft Fabric, where the semantic model and the reports live together. When it says Data-Platform-Centric, picture a separate data platform vendor whose pitch is “define your metrics in our engine, consume them everywhere.”

1. Maturity & Capability

BI-Tool-Centric Data-Platform-Centric
Calculation Power Mature expression languages with decades of investment. Time intelligence, many-to-many, calculation groups, dynamic formatting. Early-stage. Most platform semantic layers support basic aggregations and simple expressions.
Modeling Richness Star schemas, role-playing dimensions, display folders, synonyms, perspectives, hierarchies. Flat or lightly relational. Still catching up on enterprise modeling patterns.
Verdict ✅ Mature, proven at scale ⚠️ Promising but nascent

Key question to ask: “Can your semantic layer handle the 20 most complex measures in our current BI model? Show me.”

2. Performance

BI-Tool-Centric Data-Platform-Centric
Query Speed In-memory engines, aggregation tables, query folding — built for sub-second interactive analysis. Depends on warehouse engine. Adds network hops. Optimized for large-scale transforms, not slice-and-dice exploration.
User Experience Instant filter, drill, cross-highlight. Users expect this. Latency varies. Risk of degraded interactivity that frustrates business users.
Verdict ✅ Purpose-built for interactivity ⚠️ Acceptable for dashboards, risky for exploration

Key question: “When a business user applies three slicer filters on a 50M row dataset through your semantic layer — how fast does it respond in the slowest realistic scenarios, not just on average?”

3. The “Last Mile” Problem

Even if you externalize metric definitions, the BI tool still needs:

  • Conditional formatting rules
  • Visual-level filters and default aggregations
  • Display folders and field organization
  • Synonyms and linguistic metadata (for Q&A / NLP)
  • Report-level measures and layout-specific logic

The platform semantic layer doesn’t eliminate BI-tool-specific work. It just splits your logic across two places.

You still maintain the BI tool. Now you also maintain the platform layer. That’s not simplification — that’s added complexity.

4. Governance

BI-Tool-Centric Data-Platform-Centric
Single Source of Truth Already established in many orgs. Endorsed datasets, data lineage, deployment pipelines. Promises centralization but adds a new governance surface. Now you govern the platform layer AND the BI layer.
Row-Level Security Mature, integrated, tested. Must be re-implemented or passed through — another seam where things break.
Business Ownership Business analysts can see, test, and validate metrics in the tool they use daily. Metrics live in a platform business users can’t access. Ownership shifts to engineering.
Verdict ✅ Governance where users are ⚠️ Governance where engineers are

Key question: “When a business user disputes a number, can they trace the metric definition themselves — or do they need to file a ticket with the data platform team?”

5. The AI Agent Angle

This is the emerging frontier. AI agents need semantic context to reason about data. The question is: which semantic layer feeds them?

BI-Tool-Centric Data-Platform-Centric
Richness for AI BI models already contain relationships, hierarchies, descriptions, business logic — exactly what an agent needs to generate accurate answers. Metric definitions exist, but often lack the relational richness and business context an agent needs.
Proximity to Users Agents that sit on top of the BI model serve the same users who already trust that model. Agents on the platform layer may produce answers that don’t match what users see in their BI reports — eroding trust.
Maintenance One model feeds both reports and agents. Two models: one for agents (platform), one for visuals (BI). Drift risk is real.

Key question: “If my AI agent and my BI report give different answers for the same KPI, which one is wrong — and whose job is it to fix it?”

6. The Lock-In Reality

A common argument against BI-tool semantic models is lock-in. Let’s be honest about what’s really happening:

Claim Reality
“Your BI tool is locking you in!” Moving your semantic layer to any data platform is… also lock-in. You’re choosing which dependency to accept.
“We’re open and interoperable!” Every platform’s semantic layer has proprietary syntax, proprietary APIs, and proprietary tooling. “Open” is a spectrum, not a binary.
“Define once, consume everywhere!” In practice, every consuming tool interprets the layer differently, supports different subsets, and requires tool-specific workarounds.
“This is customer-driven!” The push for platform-centric semantic layers shifts the center of gravity — and revenue — to the data platform. Follow the incentives.

Key question: “If I adopt your semantic layer and want to switch data platforms in 3 years, how portable are my metric definitions?”

7. Who Actually Has This Problem?

The platform-centric approach assumes you need one semantic layer serving many BI tools. But ask yourself:

  • How many BI tools does your organization actually use at scale?
  • Of those, how much genuine metric overlap exists between them?
  • Is the overlap large enough to justify an entirely new architectural layer?

For most enterprises, the honest answer is: we’ve standardized on one BI tool, and the multi-tool problem is theoretical. The platform semantic layer is an elegant solution to a problem you probably don’t have.

The Decision Framework

To make this actionable, here’s a decision tree that walks you through the key questions. Follow the green path — if you keep answering “Yes,” you’ll end up where most enterprises belong.

Semantic Layer Decision Tree

✅ Stay BI-Tool-Centric When:

  • You’ve standardized on one primary BI tool
  • You have deep investment in existing semantic models
  • Business users own and validate metric definitions
  • Interactive query performance is critical
  • Your AI/agent strategy can sit on top of the BI model
  • You don’t have a genuine multi-tool consumption problem

⚠️ Consider Data-Platform-Centric When:

  • You genuinely operate 3+ BI tools with significant metric overlap
  • Your primary consumers are programmatic (APIs, agents, apps) rather than visual
  • You’re early in your analytics journey with no entrenched BI semantic model
  • You’re willing to accept the added complexity and governance overhead

Bottom Line

The data-platform semantic layer movement solves elegantly for a scenario that affects a minority of organizations, while introducing architectural complexity, governance fragmentation, and performance trade-offs for everyone else.

Before you rearchitect your semantic layer because you were told it’s “strategic,” ask the hard questions above. The answer for most enterprises today is: your BI tool’s semantic model is already the foundation of your semantic layer — and that’s not a weakness. It’s a huge strength.

For a deeper technical perspective on why stacking semantic models on top of each other doesn’t work, I highly recommend Chris Webb’s post Power BI And Support For Third Party Semantic Models. He explains the architectural reasons why — from SQL generation assumptions to metric aggregation conflicts — putting one semantic model on top of another creates fundamental problems that aren’t specific to any single tool.

Don’t let industry narratives make your architecture decisions. Let your users, your governance model, and your actual consumption patterns guide you.