Power BI Semantic Model Version History - An Undo Button for Web Editing

A client rang me last year on a Monday morning. Someone had edited the company's main sales semantic model in the Power BI service on Friday afternoon, "just tidying up a few measures". By Monday, half the executive dashboards showed blanks and the other half showed numbers that were confidently wrong. There was no Desktop file that matched what had been in production. Nobody could say with certainty what the model had looked like before Friday.

We rebuilt it from an older PBIX and a lot of memory. It took most of the day.

That kind of story is exactly why semantic model version history exists. As more Australian organisations shift model editing into the browser, the old safety net (a .pbix file on someone's laptop) quietly disappears, and you need something to replace it.

What it is

Semantic model version history is a feature in the Power BI service that keeps previous versions of a semantic model so you can restore one if something goes wrong. It's aimed squarely at people editing data models on the web, which has become a lot more common now that you can open a semantic model in the service and change relationships, measures, tables and properties without ever touching Power BI Desktop.

When you make edits, the service captures versions of the model in the background. From the model's version history pane, you can see the list of saved versions with timestamps and who made the change, and restore the model to one of them.

That's basically it. It's an undo button that survives closing the browser tab. I mean that as a compliment.

Microsoft's documentation has the current specifics on how many versions are kept, for how long, and which models are eligible. Those details have shifted while the feature has matured, so check the reference link at the bottom rather than trusting a number from a blog post, mine included.

Why it matters more than it sounds

Web modelling changed who edits semantic models. In the Desktop-only world, editing a model meant opening a file, making changes, and publishing. There was friction, and there was usually a file sitting somewhere that represented the "before" state, even if it was called Sales_Model_FINAL_v3_actualfinal.pbix.

On the web, there's no file. You open the model, change a measure, and it's live. That's great for speed and terrible for recoverability, unless the service keeps history for you.

We've seen three situations where version history pays for itself:

Accidental deletions. Someone deletes a table or a measure they thought was unused. It wasn't. Twelve reports break. Restore the previous version and you're back in business in minutes.

"Improvements" that change numbers. A well-intentioned change to a DAX measure that alters its logic in ways the author didn't anticipate. Version history lets you get back to the known-good state while you figure out what the change should have been.

Relationship changes. Changing a relationship's cardinality or filter direction can have surprisingly wide effects. If you didn't test it properly (and let's be honest, on the web it's easy not to), restoring is the fastest way out.

What it doesn't do

This is where I want to be clear, because I've already heard people describe version history as "source control for Power BI". It isn't.

It's not a diff tool. You can see that versions exist and restore them. You can't easily see what changed between version A and version B at a line-by-line level the way you can with Git. If you need to understand exactly which measure changed, you'll need other tools.

It's short-term. Versions are retained for a limited window and a limited number. It's for "oops, that was a mistake from earlier today" or "something broke this week", not "what did this model look like in March".

Restoring the model isn't restoring the data. Version history is about the model definition: tables, relationships, measures, properties. After a restore, you may need to refresh to get data back in line with the restored structure. Plan for that, especially on large models where a refresh takes a while.

It doesn't cover everything. There are limitations around which models and editing methods are covered. Changes pushed from external tools or via XMLA endpoints, for example, may not be captured the same way as edits in the web modelling experience. Check the documentation for your scenario before assuming you're protected.

Restoring can affect other people. If someone else made legitimate changes after the bad one, restoring an earlier version wipes those out too. Talk to your team before you hit the button on a shared model.

How it fits with Git integration and PBIP

For any semantic model that matters (the shared, certified models that feed executive reporting, finance, or anything with regulatory implications), version history should be your second line of defence, not your first.

The first line is proper source control. Power BI Projects (the PBIP format) and Fabric Git integration let you store the model definition as text files in a Git repository, with real commits, real diffs, branching, and pull requests. You can see exactly who changed what measure and why. You can review changes before they go live. You can go back years, not days.

Our usual recommendation looks like this:

• Shared, certified models: Git integration with a review process. Changes go through a branch and get looked at before merging. Web editing directly in production is restricted or discouraged.
• Team-level or departmental models: Web editing is fine, with version history as the safety net. Encourage people to connect the workspace to Git when the model starts getting reused more widely.
• Personal or experimental models: Version history alone is plenty.

This lines up nicely with the managed self-service BI pattern. The central models get the heavyweight process. Everyone else gets speed with a reasonable safety net.

Practical habits we recommend

A few things that make version history more useful when you actually need it:

Make one logical change at a time. If you change ten things in one editing session and then need to roll back one of them, you're rolling back all ten. Small, separate editing sessions give you more useful restore points.

Test before you walk away. After editing a model on the web, open a couple of the reports that depend on it. It takes two minutes and catches most of the obvious breakages while you still remember what you changed.

Limit who can edit shared models. Version history is great, but the better answer to "someone broke the production model" is "only three people can edit the production model, and they know what they're doing". Use workspace roles properly. Contributor and above can edit; Build permission alone can't.

Know where the pane is before you need it. Sounds silly, but in an incident you don't want to be hunting through menus. Have your BI team find the version history option on a test model so they're familiar with it.

Keep an eye on refresh after restore. As mentioned, restoring the definition doesn't magically put the right data back. Kick off a refresh and confirm the reports look right.

My honest take

I'm glad this feature exists. Web modelling without any version history felt like editing a production database with no backups, and plenty of organisations were doing exactly that without realising it. Version history closes most of that gap for everyday mistakes.

But I do worry a bit that teams will see "version history" and conclude they don't need Git. For small models, fair enough. For the handful of models that run your business, you want the full audit trail, code review, and long-term history that only real source control gives you. Version history is the seatbelt. Git and a deployment process are the brakes.

If you'd like help setting up a sensible model lifecycle, from Git integration through to deployment pipelines and workspace permissions, our Power BI consultants do this regularly. For organisations running Power BI inside a broader Fabric setup, our Microsoft Fabric consultants can help design the whole thing end to end. And if you're starting to put Copilot or AI agents on top of your semantic models, that's another reason to keep the models stable and well-governed, which our AI for business intelligence work covers.

Reference: Use semantic model version history (Microsoft Learn)