In the previous article, we explained that Microsoft have released several new features to help Power BI developers to do more and enhance productivity. These tools are additions to Power BI Desktop or Fabric that help fill existing gaps in the product. You can use them with or without third party tools like Tabular Editor, which is an integrated development environment (IDE) to help you make better semantic models as effectively as possible.
The following diagram (from the previous article) is a high-level overview of these features and tools, and how you can use them with local models (in Power BI Desktop) or remote models (in a Fabric or Power BI workspace).
We are releasing free introductory courses about all these features and tools, which you can find on your learning platform at Tabular Editor Learn.
In this article, we will explain some of the differences between these tools and features, but also how they are similar: that they help you scale your tasks both within and across semantic models.
All these tools have one thing in common: they help you be productive and effective by scaling your tasks. By scaling we mean that you can either:
Each of these tools help you scale tasks in different ways, which we explain and compare in the following two sections, looking at how they help you scale within a model and then across multiple models. In these sections, we will also introduce and explain each of these tools in a bit more detail.
Within a model, you can scale tasks by batch applying changes and performing many operations at once, or reusing various objects and patterns by applying atomic design principles.
Tools that can help you do this include Tabular Editor, the TMDL view, the DAX query view, and notebooks (for published models and if you have access to a Fabric workspace).
A core focus of Tabular Editor is to give you tools and methods that you can use to scale any task within a single model. This is where Tabular Editor excels, and how a developer saves the most time or gets the best experience when working with a model. A few specific ways that Tabular Editor enables scaling of tasks include:
A more novel way people scale tasks in Tabular Editor is by using C# scripts that call LLM APIs. These scripts send a prompt together with model context (such as the objects you select and a sample of values) to generate output. Community examples include:
You can't really talk about tooling without touching on generative AI. People mostly use AI to generate suggestions for properties (like descriptions, translations, and display folders) or code (DAX or Power Query; M).
In the context of scaling tasks within a model, AI is helpful to aid in bulk-generation of these properties. Copilot for Power BI is of limited help here, since it can only make bulk changes to a model via the DAX query view (which we discuss further below). In general, though, when it comes to scaling tasks, you are going to be leveraging AI through another tool, like C# scripts in Tabular Editor (which call an API, like Claude from Anthropic), or the TMDL view (where you can open TMDL scripts in VS code and edit them with GitHub Copilot).
To be direct, we're not yet at the stage where AI reliably makes the semantic model for you. At best, it amplifies and augments existing tools to make them more useful or convenient.
In the future, we are likely to see further advances in how AI helps you build a semantic model, but also how AI uses your model to answer data questions or even how AI agents execute certain pre-instructed tasks.
The TMDL view is a separate window that you can view in Power BI Desktop like the canvas (where you add visuals) and the data view (where you view and interact with table data in an import model). In this window, you can create one or more TMDL scripts, which let you directly make changes to model metadata (in TMDL format). Any changes that you make can be previewed with a diff of the (TMDL) model metadata, showing it before and after you run the script.
Here is an example of what the TMDL view looks like, with a TMDL script on the left that has several changes previewed beside it:
The Tabular Model Definition Language (TMDL) is a serialized model metadata format from Microsoft. According to its creator Mathias Thierbach, it was inspired by the YAML-like DAX script syntax in Tabular Editor 3. The purpose of this metadata format is to make the model metadata easier to read and manage, such as with source control. You can save your model using the TMDL format in Tabular Editor, or when you save in Power BI Desktop as a Power BI Project (or .pbip format). You don’t need to save your model as TMDL or PBIP to use the TMDL view.
It's worth clearing up the confusion: “TMDL” isn't the same as “the TMDL view”. TMDL is a serialized model metadata format; in the TMDL view you create TMDL scripts that show your model metadata using that format. These scripts have a limited syntax, not comparable to Python or C# scripts. The difference between a TMDL script and TMDL metadata is that the script contains a few keywords (verbs) like createOrReplace; more verbs, similar to TMSL scripts, will likely be added in the future.
You can drag one or more objects onto the TMDL view (from the data pane or model explorer) to generate a TMDL script for them. You can even create a script for the entire model this way. Any scripts you save in a PBIP file are accessible as .tmdl files, which you can also open and manage from VS Code with GitHub Copilot, for instance. As of version 3.21.0, Tabular Editor 3 also lets you click-select to get TMDL scripts from your model or any selected object while you work.
The following diagram shows how you can access any TMDL scripts that you save in Power BI, if you save your model as a Power BI Project (.pbip) format.
Note that you can also create C# scripts and macros from Tabular Editor in VS Code with a similar approach, as explained by Microsoft MVP Bernat Agulló Roselló.
Thus, use-cases for the TMDL view include (but aren’t limited to):
We have tutorials and examples on these use-cases and more in our course The TMDL View: A Practical Introduction, which we are releasing in May 2025.
There are also some considerations and limitations to keep in mind with TMDL scripts:
Ctrl + Spacebar at any time to see the list of valid properties (or keywords), but understanding what those properties do means that you must first check Analysis Services documentation or explanations from other sources.IsPrivate, the table will disappear from Power BI Desktop. If you then delete that TMDL script from the TMDL view, you have no easy way of making that table visible again; you have to script the entire semantic model to see it, since the table disappears from the data pane. Alternatively, you can manually rewrite that TMDL script, modify the metadata files, or use a third-party tool.Selected.Measures or Selected.Columns) so that actions and patterns are reusable irrespective of whatever model you’re connected to.These limitations are minor. The TMDL view is a great entry point for model developers to use code to manage semantic models: it's simple, accessible, and useful at any experience level.
Like the TMDL view, the DAX query view is a separate window that allows you to write DAX queries that you can use to query your model. An example of a DAX query in the DAX query view is below:
Use cases for the DAX query view include (but are not limited to):
The DAX query view in Power BI Desktop is powerful and useful. However, some people in the community ask about the difference between this and the DAX query views in DAX studio or Tabular Editor.
You typically use DAX Studio over the DAX query view in Power BI Desktop for the following reasons:
You typically use the DAX query view in Tabular Editor 3 over the DAX query view in Power BI Desktop for the following reasons:
The DAX query view in Power BI, DAX Studio, and Tabular Editor all let you write and evaluate DAX queries; it might just come down to user preference about which one you use. However, there are specific cases when you might opt for one or another tool.
None of these query views is “better” than another; it's like comparing screwdrivers. Focus on when to leverage each, depending on your problem. This “toolbox” mentality sets you up for more success than sticking to one preferred tool.
In Fabric, you can create code notebooks, where you can write and run code in cells, such as Python, Spark, and other languages. Notebooks are a structured way to construct and present code for transforming data, managing artifacts, or sharing analyses and visualizations. Each cell's output shows beneath it, and you can schedule notebooks to run and share them with collaborators.
Notebooks in Fabric are unique because there are two exclusive libraries that enable you to connect to, use, and manage semantic models: Semantic Link, and semantic link labs.
With a few simple functions these libraries connect to published models in any workspace (not just Fabric, but also Pro or PPU workspaces for some functions). That enables not only model analysis but also creating, changing, and managing models with Python. The libraries are streamlined enough that you don't have to be a Python expert to get value from them.
With notebooks, you can view or change any model property by using Python code. When you set up the notebook appropriately, you can also easily reuse it as well, changing just a few constants to apply changes to other models or reports. The following diagram shows some examples of when you might choose between DAX scripts or C# scripts in Tabular Editor, notebooks, or the TMDL view to make model changes:
Notebooks are unique for reasons like the following (but not limited to these):
When you are developing a single model, you can use notebooks to save time with the following tasks (which are some examples, and not a complete list):
Notebooks also have some limitations that you should keep in mind:
For a semantic model, a notebook is more likely a supplemental tool for specific tasks than your primary development tool. You can build and test a model entirely with Python code, but it's rarely the most efficient way compared to a user interface in Power BI or Tabular Editor, which gives less friction for development, exploration, and organization.
The benefits of a notebook for a single item are more significant for reports, which until now, have had no official tools to support bulk changes outside of Power BI Desktop. For instance, with a bit of Python code, you can now make formatting changes to multiple visuals in bulk, including changing colors, fields, settings, and more. It’s also possible to reuse report pages, visuals, or visual elements as templates for new reports, with significant potential time-savings for report developers. We give many examples of this in the later modules of our coming Notebooks introduction course on Tabular Editor Learn.
Again, a notebook isn't a primary development tool for reports, but a specialized one to reach for when you can save time or do things a user interface can't. This is particularly true when it comes to scaling across items (rather than within them), which we discuss, below.
Typically, semantic model developers, Fabric administrators, or other roles manage or govern more than one model in a workspace and organization. In these scenarios, they need the tools and resources to be able to check, monitor, and possibly even change multiple models at once. In organizations that have a self-service model where decentralized analytics teams or business users make their own models, this is particularly important for the following reasons:
The following tools help you scale tasks across many models.
Since Tabular Editor is an IDE, its focus is to help you work with one model at a time. You can certainly have multiple instances of Tabular Editor running at once (for example to copy measures, tables, columns, or properties from one model to another). However, the focus of Tabular Editor is for you to scale your tasks within one model rather than across many models.
That said, Tabular Editor does have a command line interface (CLI) which you can use in custom solutions with multiple models. For instance, you can automate DAX queries against models using the XMLA endpoint or run the best practice analyzer (BPA) to identify BPA rule violations. However, the main intent and purpose of the CLI is to support deployment in CI/CD scenarios.
The main benefit of notebooks is that you now have an easy way to programmatically make changes to multiple published models and reports at once, thanks to semantic link and semantic link labs. You no longer have to wade through complex technical set up to do basic tasks with the APIs, like check the total number of semantic models or reports, automatically run queries against a model and validate the result, and more.
This makes notebooks an invaluable tool for centralized teams or administrators who manage a Power BI tenant. This is true even for organizations who haven't adopted Fabric, since notebooks can be used to survey, analyze, and even change items in workspaces with PPU and Pro license modes. This means that a small team of experts can leverage a single F2 workspace that they pause-and-unpause, getting tremendous value across their tenant for a few Euros each month.
Note however that you can only use a subset of the semantic link and semantic link labs functions with Pro workspaces. Some functions use the same libraries as Tabular Editor to interact with the model, and thus require an XMLA read/write endpoint is enabled. For instance, you can’t run the BPA over models in a Pro workspace.
There are also extensions which let you manage items in a workspace and their definitions, such as Fabric studio (from Gerhard Brueckl), Microsoft Fabric, Fabric Data Engineering, and Fabric User Data Functions (UDFs) (From Microsoft). These extensions are particularly useful if you use VS code for other tasks, such as local development of notebooks or as a Git client for committing changes to your semantic models and reports. Fabric studio in particular can be a convenient way to manage and use workspace items, while also providing easy access to their definition.
The Power BI tool ecosystem is the richest and most abundant that it has ever been. For pro developers, this is a boon that gives us more options and approaches to be effective and efficient in our tasks. Each of these tools have scenarios and problems that they are tailored to address, but you might also prefer one over another (even if it is less “optimal”) for subjective reasons, and that is fine. Ultimately, what matters most is that you know what tools are available at your disposal, and how you can make better data models, faster.
Take your semantic models further with Tabular Editor.
Give Tabular Editor a spin