Advanced Data Model Management in Power BI - XMLA, Tabular Editor and Proper Source Control

At some point every serious Power BI team hits the same wall. The main semantic model has grown to 200 measures, a dozen fact tables and a few hundred thousand lines of history in the .pbix. Two people need to work on it at once and they can't, because a .pbix is a binary file and merging two of them is not a thing. Someone wants to add a calculation group and discovers Power BI Desktop's support for advanced model features has always lagged behind what the engine can do. Every deployment involves somebody opening Desktop, hitting publish, and hoping.

That's the point where Microsoft's advanced data model management usage scenario becomes relevant. It's one of the Power BI implementation planning scenarios, and the core idea is simple: for important, complex semantic models, stop treating Power BI Desktop as the only authoring tool and start managing the model like the enterprise asset it is. The Microsoft article is here: Power BI usage scenarios - Advanced data model management.

We've moved quite a few Australian clients onto this approach. It's a big quality-of-life improvement for the BI team. It also has a few one-way doors that you need to know about before you walk through them.

What the scenario covers

In short, the semantic model gets developed and maintained using tools other than (or as well as) Power BI Desktop, connecting to the model through the XMLA endpoint.

The pieces that usually come together:

• The XMLA read/write endpoint. Every semantic model on Premium, Premium Per User or Fabric capacity exposes an endpoint that speaks the same protocol as Analysis Services. With read/write enabled, external tools can connect and change the model directly in the service.
• Third-party tools. Tabular Editor is the big one. DAX Studio for query analysis and performance tuning. ALM Toolkit for comparing and deploying model differences. These are the tools experienced Analysis Services developers have used for years.
• Text-based model definitions. Power BI Project files (.pbip) and TMDL (Tabular Model Definition Language) store the model as human-readable text, one file per table, measure set and so on. That means real source control, real diffs and real merges.
• Git integration and deployment pipelines. Fabric workspaces can sync to Azure DevOps or GitHub repos, and deployment pipelines move content between dev, test and production.

You don't need all of these on day one. But the scenario really is the sum of them: the model is defined in code, versioned properly, edited with tools that expose the whole engine, and deployed through a controlled process.

Why bother

I'll give you the reasons that actually convince clients, not the brochure version.

Multiple developers can work on the same model. With the model in TMDL in a Git repo, one person can work on finance measures while another adds a new inventory table, and Git handles the merge. On a .pbix this is impossible. I've watched BI teams use a shared spreadsheet to "book" the .pbix file so two people didn't overwrite each other. That's not a process, that's a cry for help.

You get access to features Desktop doesn't fully expose. Calculation groups were the classic example for years. Perspectives, object-level security, detailed partition management, custom incremental refresh policies, translations. Desktop has caught up on some of these, but Tabular Editor still exposes the full Tabular Object Model and lets you script bulk changes. Adding format strings to 150 measures by hand in Desktop is a miserable afternoon. In Tabular Editor it's a short C# script.

Metadata-only deployments. When you deploy a change through the XMLA endpoint, you can push the model metadata without republishing the data. For a large model that takes an hour to refresh, that's the difference between "deploy a measure fix at lunch" and "deploy it tonight and hope the refresh finishes before 7am."

Partition-level refresh. You can refresh specific partitions, say just the current month of a large fact table, rather than the whole model. Combined with custom partitioning, this is how big models stay manageable.

Proper review. When a measure change is a diff in a pull request, a second person can actually review it. You can see that someone changed the filter in the Gross Margin measure. In a .pbix world, changes are invisible until a number looks wrong in a board pack.

The one-way doors

This is the part I make sure every client hears before we start.

Once you modify a model through the XMLA endpoint, you generally can't download it back as a .pbix. The service-side model has been changed in a way Desktop can't round-trip. If your team's whole workflow assumes "download the pbix, edit, republish," that workflow stops working for that model. This is fine if you've moved the source of truth into a Git repo with TMDL or .pbip files. It's a nasty surprise if someone just connected Tabular Editor to production to "quickly fix a measure."

It needs capacity. XMLA read/write requires Premium, Premium Per User or Fabric capacity. If you're on Pro only, this scenario isn't available. For many mid-sized Australian organisations this ends up being part of the case for an F SKU, along with everything else Fabric brings.

The admin setting has to be on. XMLA endpoint read/write is a capacity setting. Some organisations have it set to read-only or off by default for good governance reasons. Talk to your Power BI or Fabric admin early.

Report and model separation becomes mandatory in practice. If you're managing the model in code and deploying it independently, reports need to live separately and connect to the shared model live. Teams who are used to building the model and the report in one .pbix need to change habits. Honestly they should do this anyway, but this scenario forces it.

Who should be doing this

Not everyone. This scenario is for the people who own your most important shared models, typically a central BI team or a small group of experienced data modellers. If you're running managed self-service BI, these are the people building the data layer.

The skill bar is real. Tabular Editor gives you direct access to the model with fewer guardrails than Desktop. You can break things. Your developers need to understand the Tabular Object Model, be comfortable with Git branching and pull requests, and know how DAX and storage modes behave in production. A good Power BI report builder isn't automatically ready for this. Plan for some training and pairing.

On the plus side, developers who come from a software background usually love it. Once the model is text in a repo, it feels like normal engineering work. Branch, change, test, PR, merge, deploy. Several of our .NET developers who'd previously avoided Power BI became quite keen on it once they saw TMDL in VS Code.

How we usually roll it out

There's a sequence that works well for us. Rushing it causes problems.

1. Pick one model. Start with your most important, most actively developed semantic model. Not all of them.
2. Save it as a Power BI Project. Convert the .pbix to .pbip format with TMDL and commit it to a Git repo. This is now the source of truth.
3. Set up workspace Git integration for a dev workspace, connected to the repo. Developers work in branches, either in Desktop with the project files or in Tabular Editor.
4. Introduce Tabular Editor for the things Desktop is painful at: bulk edits, calculation groups, Best Practice Analyzer rules. The BPA alone catches a surprising number of issues in existing models, like unused columns, measures without format strings, and bi-directional relationships nobody remembers adding.
5. Add a deployment process. Fabric deployment pipelines are the simplest option. For more control, Azure DevOps or GitHub Actions running Tabular Editor CLI or similar can deploy to test and production workspaces, run BPA checks and fail the build if rules are broken.
6. Lock down production. Once the pipeline is working, stop people editing production directly. Changes go through the repo or they don't go in.

The first model usually takes a few weeks to bed in, mostly because of the process changes rather than the technology. After that, moving other models across is pretty quick.

What's still rough

A few honest observations.

Git integration in Fabric has improved a lot, but it's not as smooth as working with code in a normal software repo. Conflicts in some files are still awkward to resolve, and the error messages when sync fails could be more helpful. Expect some friction.

Report files (.pbir) in source control are also better than they were, but reports are still much harder to diff and review meaningfully than models. We generally focus the rigorous review process on the model and accept that report changes get a lighter touch.

Tool licensing is worth checking. Tabular Editor 2 is free and open source. Tabular Editor 3 is a paid product with a much nicer development experience. For a team doing this daily, TE3 is worth paying for, but factor it into the budget.

And documentation inside organisations tends to lag. Once the model is code, people assume it's self-documenting. It isn't. Use descriptions on measures and tables, which TMDL stores nicely, and keep a short README in the repo explaining how to build and deploy.

Is your team ready?

A quick test. If any of these are true, it's probably time:

• More than one person regularly needs to edit the same semantic model
• The model is large enough that full refreshes are a scheduling problem
• You've had a production incident caused by an untracked change to a measure
• You want calculation groups, OLS or custom partitions and Desktop is getting in the way
• Your organisation expects change control on financial reporting

If none of those apply, Desktop is probably still fine, and adding Git and XMLA tooling would be process for the sake of process.

Where we can help

We help Australian organisations set up proper model management in Power BI and Fabric: converting existing models to TMDL, setting up Git and deployment pipelines, training BI teams on Tabular Editor, and cleaning up models that grew without much discipline. Our Power BI consultants do this hands-on, and if you're moving to Fabric capacity as part of the change, our Microsoft Fabric consultants can help with the platform side. If you want to talk through whether it's the right time for your team, get in touch.