Power BI Notebooks With Your Semantic Model - What They Are Good For

For years, working with a Power BI semantic model meant opening Power BI Desktop, fiddling around in the modelling view, and trying to remember whether you wanted a measure or a calculated column. If you wanted to do something programmatic, you reached for Tabular Editor or wrote some XMLA scripts and hoped for the best. The recent addition of notebook support for semantic models in the Fabric service quietly changes that workflow. It is not flashy, but it is genuinely useful for a few specific jobs that used to be painful.

I want to talk through where this fits in the real consulting work we do for Australian businesses, what holds up well, and where you should probably not rely on it yet.

What this actually is

A Fabric notebook is a Python or Spark environment running inside the service. The new capability is that you can connect a notebook to a published Power BI semantic model and either read data out of it or push changes back into it. Microsoft uses the SemPy library (semantic-link) to do the heavy lifting. You import it, you point at a workspace and model, and you get a pandas-shaped view of the underlying data, plus tools to query measures, list relationships, and even modify the model definition.

If you have never used Jupyter notebooks before, think of it as a way to run small chunks of Python code one block at a time, with the output appearing right underneath each block. Brilliant for exploration. Less brilliant for anything you want to run reliably for the next five years without someone babysitting it.

The jobs it actually does well

Three things I have found this genuinely good for so far.

The first is auditing models. We get pulled into projects where a Power BI deployment has been growing for two or three years, nobody has documented anything, and there are now 400 measures across 30 tables. Opening that in Power BI Desktop and trying to make sense of it is brutal. With a notebook, you can list every measure, every relationship, every column with its data type, and every dependency in seconds. You can dump it all into a dataframe, filter it, sort it, and write it to an Excel file for the client. We did exactly this for a logistics customer in Brisbane last quarter and turned what would have been a two-day reverse engineering exercise into half a day.

The second is data validation. If you have a semantic model that other reports depend on, you really want some confidence that the numbers coming out match the source system. With a notebook, you can run a DAX query against the model, run a SQL query against the source, and compare the results in pandas. Schedule the notebook with a Data Pipeline and you have a daily reconciliation check that emails you when revenue in the model drifts from revenue in the warehouse. We build this kind of safety net into most of our Microsoft Fabric work now because the cost of a stale or wrong number reaching the executive team is high and the cost of the check is essentially nothing.

The third is bulk model changes. Renaming 50 measures to follow a consistent naming convention is the kind of work that takes a junior consultant two days and produces typos. Doing it in a notebook with a regex find-and-replace across the model definition takes 20 minutes and is reproducible. Same for adding format strings, hiding columns, or tagging measures with descriptions. The notebook is essentially a programmable version of the model.

The bits that are still rough

This is not a finished product. A few things you should know before betting anything important on it.

The library evolves quickly and method names change. Code you wrote six months ago might not work today. If you are putting notebooks into production, pin your library versions and accept that you will revisit them every few months.

Authentication can be fiddly when the notebook needs to read from sources outside the workspace. You can run the notebook as a service principal, but then the service principal needs explicit access to the model and to whatever you are comparing against. Plan the identity story before you write any code.

Performance is fine for small to medium models but degrades on very large semantic models. If you have a 50GB Direct Lake model, pulling the whole thing into pandas is not the move. Use DAX queries with WHERE clauses to filter at the source instead of in Python.

The model modification side is genuinely powerful but it is also genuinely dangerous. There is no undo button. If you run a script that renames every column to lowercase, every report consuming that model breaks. Always test against a copy of the model first. We have a workflow where we deploy a clone of the production model into a dev workspace, run the changes there, validate, and then promote through a Deployment Pipeline. Slower but boring beats exciting when production is involved.

Error messages are sometimes opaque. You will occasionally get an authentication error that actually means a different thing, or a method call will fail with a generic Python exception that gives no clue about which part of the model object it choked on. Read the source code on GitHub if you get stuck. It is usually easier than the docs.

Where it fits in a real Australian Power BI practice

Most of our clients are not doing anything exotic with Power BI. They want reports, they want them fast, they want them reliable, and they do not want to spend their lives debugging refresh failures. So how does a notebook fit into that?

For greenfield projects, mostly it doesn't. You build the model in Power BI Desktop or Tabular Editor like you always have. Notebooks come in later, for the kind of operational work that emerges once a model is in production.

The clearest use case I have seen is for customers running a lot of semantic models. If you have five or ten models across the business, a notebook becomes a way to enforce consistency. You can audit all of them for missing descriptions, check that every fact table has a date relationship, look for unused columns that are bloating the model, and produce a report that goes to the data team weekly. We have set this up for a couple of Australian organisations and the data team finds it genuinely useful because it surfaces problems before users notice them.

The other clear use case is integrating semantic models with external systems. Maybe you want to push a measure value into a Teams adaptive card every morning. Maybe you want to write reconciliation results into a SharePoint list. Notebooks plus the rest of the Fabric ecosystem make this kind of glue work much easier than it used to be when you were stuck with the XMLA endpoint and a PowerShell script.

Practical tips if you are getting started

A few things I tell consultants on my team when they pick this up.

Start with read operations only. Build confidence by querying models, listing objects, and comparing data before you ever try to modify a model. Read-only operations cannot break anything.

Get familiar with fabric.list_tables, fabric.list_measures, and fabric.evaluate_dax. These three functions cover 80% of what you actually want to do day to day.

Save your notebooks somewhere sensible. The Fabric workspace itself is fine for development but if a notebook is doing important operational work, the code should also live in source control. Git integration in Fabric is improving and we typically wire it up early on serious projects.

Test your DAX queries in Power BI Desktop first. DAX inside a notebook still has all the same gotchas as DAX inside a report. Get the query working in the place with the best authoring experience, then paste it into the notebook.

If you are doing model modifications, write the changes you want to make as a list of operations first, in plain text. Then translate them to code. The temptation to start coding immediately leads to half-finished changes and inconsistent results.

When to call someone

Notebooks with semantic models are not difficult to learn for anyone comfortable with Python and DAX. But there is a difference between "I can write a notebook" and "I have a production-grade workflow that I trust to manage 30 critical models." If you are at the second stage, or you want to be, that is the kind of work we do every week. We help Power BI teams in Australia move from one-off heroics to repeatable engineering practice, and notebooks are increasingly part of that toolkit.

For organisations earlier in their Fabric journey, the question is usually whether semantic models are even the right pattern for what you are trying to do. Sometimes a notebook is the wrong answer because the model is the wrong answer. That conversation is worth having with someone who has done it a few times.

Final thoughts

Notebooks talking to semantic models are not going to change how most people use Power BI. Business users will still build reports in Desktop, and that is fine. What this capability does is give the data engineering side of the house a proper way to manage, audit, and integrate Power BI models without leaving the Fabric environment.

It is early. The tooling is good enough to be useful for real work but still rough enough that you have to be careful. Used well, it can take a meaningful amount of pain out of running a large Power BI estate. Used badly, it can make a mess of a production model in about 30 seconds. Treat it the way you would treat any other piece of code that talks to production data, and you will get a lot out of it.

Reference: Use notebooks with your semantic model on Microsoft Learn.