Power BI Desktop

This is your main development tool, and you should get it installed on your PC. Currently, there are two ways you can install it:

1. As a standard Windows Application (by downloading the .exe installer).

2. As a Store App (via the Microsoft Store).

The advantage of installing it as an App is that, in most cases, you do not need Administrator rights on your PC, and you get auto-updates (usually once per month). On the other hand, if you install via the .exe installer, you have full control over the installed version and when updates occur.

Power BI Desktop is a very versatile tool. It can be used for the development of Semantic Model parts and for Report/Visuals (GUI) parts, all in one place.

Visual Studio + PBI Desktop

Large organizations—especially if the semantic models are finally deployed on Microsoft Analysis Services—might use Visual Studio as the main development tool for the semantic model part, and Power BI Desktop for the visual reporting layer.

The Essential External Tools

While today’s Power BI Desktop is able to do more and more on its own, some external tools are still vital for the professional developer. I would emphasize three of them as the most useful on a daily basis.

1. DAX Studio

While Power BI lets you write DAX, DAX Studio lets you analyze exactly how those calculations run. It is the industry standard for troubleshooting slow reports, allowing you to view Server Timings to pinpoint bottlenecks in your code. Beyond optimization, it is also a fantastic tool for formatting complex DAX measures and extracting data directly from your model.

2. Tabular Editor (TE2 & TE3)

Tabular Editor is the ultimate tool for managing your semantic model’s metadata efficiently. It comes in two flavors:

• Tabular Editor 2 (TE2): A free, open-source version that is perfect for batch updates, scripting, and advanced model management.

• Tabular Editor 3 (TE3): A commercial, full-featured development environment. While TE2 handles the core mechanics beautifully, TE3 adds a premium layer with a dedicated DAX Debugger, IntelliSense, and a rich interface for testing code before it ever hits your report.

3. ALM Toolkit

This tool is essential for teams. It compares two Power BI files (e.g., Development vs. Production) and highlights the differences line-by-line. It allows you to merge changes without accidentally overwriting the entire dataset.

A Few More Useful Tools

• Bravo for Power BI: The most user-friendly tool for beginners and pros alike. It instantly generates compliant Date/Calendar tables, applies best-practice formatting to your measures, and helps you optimize model size with a beautiful interface.

• Measure Killer: As reports grow, they accumulate “dead” code. Measure Killer scans your entire report (and your cloud environment) to find measures and columns that are never used, allowing you to safely delete them to speed up your model.

• Power BI Helper: Generates automatic documentation of your model, shows you lineage (which columns feed which visuals), and helps you reverse-engineer reports inherited from others.

(There are many more—just search for “must have Power BI external tools” on the web.)

The Deployment Process

It is important to clearly separate the lifecycle into two distinct phases: the Development Phase and the Consumption Phase.

The Development Phase

This is typically carried out by BI Developers or Data Analysts. The goal here is to translate business requirements into robust semantic models and insightful reports. The tools mentioned above (DAX Studio, Tabular Editor, etc.) are almost exclusively used during this phase to build and optimize the solution.

The Consumption Phase

This is where business users interact with the data to derive value. While Power BI Desktop can technically display reports, it is primarily designed for authoring. Ideally, consumption happens on the web via the Power BI Service, ensuring users are always looking at the latest version of the data without the complexity of the developer interface.

Report Publishing

Publishing is the bridge between these two worlds. It is the process of transferring your work from the local environment to the cloud. Crucially, when you publish a Power BI Desktop file (.pbix), it technically splits into two separate components in the Service:

1. The Semantic Model (The data and logic)

2. The Report (The visuals and canvas)

Please see the diagram below.

Managing the Lifecycle

Once you understand this diagram, a critical realization follows: after deployment, you essentially have two copies of the same semantic model—one running locally on your PC, and one live in the Web Service (Production).

While they start out identical, they will inevitably deviate as you continue developing new features locally. This is where tools like ALM Toolkit become essential. They allow you to compare your local “Work in Progress” model against the “Live” production model to see exactly what has changed before you publish again.

The Core Takeaway

The most important lesson here is that the Semantic Model is the heart of your Power BI solution. Whether it is currently sitting on your local laptop during development or hosting thousands of users in the cloud, it remains the central engine. The power of the external tools we discussed lies in their ability to connect to this model wherever it resides—local or cloud—to help you optimize, debug, and manage it effectively.

The Rise of Self-Service BI

Traditionally, organizations operated in two distinct silos: IT Developers, who owned the creation tools, and Business Users, who were limited to simply viewing reports on the web. The fundamental flaw in this model is the bottleneck: business demand for new insights (the demand) always outpaces the IT department’s capacity to build them (the supply).

This is where Self-Service BI (SSBI) users come into the picture. These are skilled business professionals who are not afraid to solve immediate problems themselves.

Consider a scenario where a “Corporate Semantic Model” is published in production. It defines the core business entities and serves 90% of the organization’s needs. However, a local business unit often has specific, niche requirements—perhaps a new measure for a quarterly review or a budget target that only exists in a local Excel file.

Instead of submitting a formal request to IT and waiting weeks, an SSBI user can connect to and extend the corporate model. Here are the primary ways SSBI users can leverage this:

• Power BI Desktop (Live Connection): The user connects a blank Power BI file to the published corporate model. In this mode, they cannot change the underlying data structure, but they can author new report pages, build new visuals, and write report-level measures. This allows for custom storytelling while still using trusted corporate data.

• Power BI Desktop (Composite Models): This takes capability a step further. The user converts the connection into a Mixed Mode model, allowing them to mash up corporate data with local data. For example, they can import a local Excel budget file, relate it to the corporate “Sales” table, and even add new calculated columns. This creates a specialized “local extension” of the main model.

• Excel Integration (Analyze in Excel & Get Data): For finance professionals and analysts who live in spreadsheets, this is a game-changer. Users can connect Excel directly to the corporate semantic model. They can choose to build standard Pivot Tables for aggregated reporting, or for more advanced scenarios, use DAX Table Expressions to import specific flat tables of live data directly into an Excel sheet.

The Collaborative Future

If these local business units are given their own Power BI Workspace, they can even publish these “extended” reports back to the web. This allows them to share specialized insights with colleagues while maintaining a single version of the truth for the underlying data.

Conclusion: The Chef, The Kitchen, and The Feast

Building a successful data culture isn’t just about having the right ingredients (data); it’s about having the right kitchen setup. We have explored how Power BI Desktop acts as your main workstation, but true professional capability comes from integrating external tools like DAX Studio for performance, Tabular Editor for speed, and ALM Toolkit for safety.

Crucially, we debunked the myth that development is solely an “IT job.” By understanding the separation between the Semantic Model and the Report, we empower Self-Service BI users to connect, extend, and innovate without breaking the core foundation.

Your Next Step: If you are still only using Power BI Desktop, pick one external tool from this list today—perhaps Bravo for quick formatting or DAX Studio to inspect a slow query—and install it. You will be surprised at how much faster your “cooking” becomes.

Want to dive deeper? Browse the full library by category on the Topics Page.

In my last article, Why the Semantic Model is Your Most Valuable Asset, we established a hard truth: Your visual report is disposable, but your Semantic Model is the gold in the vault.

But an asset sitting in a vault earns zero interest. You need to invest in it.

Too many organizations treat their Semantic Models like single-purpose tools. They build a sophisticated model, slap one report on top of it, and call it done. That is a massive waste of ROI. In a mature Data Architecture, the Semantic Model isn’t just a data source for a dashboard—it is the Solar System of your entire organization.

The Semantic Model is the Sun. Burning bright in the center, it holds the “Single Version of the Truth.” Orbiting around it are different ways to consume that truth.

Here are the 7 Ways to Harvest Your Semantic Model to ensure every person in your company—from the CEO to the Data Scientist—is looking at the same star.

1. Power BI Reports (The Interactive View)

• Target Audience: Executives & Managers

• The Method: Live Connection (Web/Desktop)

This is the standard use case. We build interactive, visual dashboards to spot trends and outliers. We all know this one.

The Architect’s Note: Remember that the report is just a skin. If you delete the report file tomorrow, your business logic (Measures, KPIs, Security) remains safe in the model. Never put business logic in the visual layer; keep it in the model so the other 6 tools below can use it.

2. Paginated Reports (The Document View)

• Target Audience: Operations & Regulatory Compliance

• The Method: Power BI Report Builder

Sometimes you don’t need a dashboard; you need a pixel-perfect invoice, a regulatory PDF, or a 50-page operational list that prints perfectly on A4 paper.

Paginated Reports connect to the same Semantic Model to generate these formal documents. This ensures that the numbers on the invoice match the numbers on the dashboard exactly.

3. Excel (The Financial View)

• Target Audience: Finance & Controllers

• The Method: Power Pivot / DAX Table Expressions

Finance teams generally do not want bubbles and maps; they want grids, pivots, and ad-hoc analysis. Instead of forcing them to export data to CSV (creating “Excel Hell” and version control chaos), you give them a Live Connection.

Using “Analyze in Excel,” they connect directly to the Semantic Model. They can browse the exact same “Gross Margin” measure as the CEO, but they do it in their native language: Pivot Tables. One model, two interfaces.

4. Composite Data Models (The Extension View)

• Target Audience: Departmental Analysts (”Shadow IT”)

• The Method: DirectQuery for Power BI Datasets

This is the ultimate “Ecosystem” feature. It allows a local department (like HR or Marketing) to connect to your corporate “Golden Dataset” and extend it with their own local Excel files or flat files.

They don’t rebuild your work; they build on top of it. They harvest your core architecture while maintaining the flexibility to add their own local analysis.

5. Semantic Link (The Scientific View)

• Target Audience: Data Scientists & Python Developers

• The Method: Microsoft Fabric (sempy library)

This is the game-changer introduced in Microsoft Fabric. Historically, Data Scientists had to rebuild business logic in Python to run forecasts because they couldn’t read Power BI files.

Now, using Semantic Link, they can import your Power BI measures directly into their Python Notebooks as a Pandas DataFrame. Your Machine Learning models now speak the exact same language as your Financial Reports. No more “Two Versions of the Truth.”

6. AI Agents & Copilot (The Conversational View)

• Target Audience: Everyone

• The Method: Natural Language Query (NLQ)

This is the newest planet in our solar system. Executives can now ask, “Why is Gross Margin down in Europe?” and the AI agent harvests the answer directly from your measure definitions.

Technically, Copilot acts as a Translation Layer. It translates English into a DAX query, executes it against your model, and renders the result. This makes your Semantic Model the “Vocabulary” for the company’s AI. If your metadata is clean, your AI is smart.

7. Power Apps (The Action View)

• Target Audience: Frontline Workers

• The Method: Power Automate Bridge / Native Integration

Dashboards are passive; they show you what happened. Apps are active; they let you fix it. By connecting a Power App to your ecosystem, frontline workers can “harvest” context from the model (e.g., “Stock is low”) and take action.

• The Harvest: The App reads the data (via Power Automate or Native Integration).

• The Action: The user clicks “Restock.”

• The Write-Back: The App writes the transaction back to the Source System (SQL/Dataverse), closing the loop between insight and action.

The Verdict

If you are a Solution Architect, your job isn’t to build a Report. Your job is to build the Sun.

Once you have a solid, well-governed Semantic Model, you can let the users choose their own telescope. Whether they use Excel, Python, or a Mobile App, they are all looking at the same truth.

Build once. Harvest everywhere.

Want to dive deeper? Browse the full library by category on the Topics Page.

I want to share my reasoning on why the Power BI Semantic Model is, as of today, your organization’s most valuable analytics asset.

First, we must admit that technology is evolving at breakneck speed. New tools emerge every day. Three years ago, we heard about ChatGPT for the first time. Today, you only need to look at the LM Arena leaderboard to see how many new AI models are emerging and competing for dominance: Gemini, Grok, Claude, and so on.

The data landscape is shifting just as fast. We have modern environments providing the “Data Lake” concept, like Microsoft Fabric, Databricks, and Snowflake. And let’s not forget the traditional data storage tools that still run the world: SQL databases, SharePoint lists, and finally, physical files like Excel or CSV.

The Problem: The Distributed Truth

Traditionally, medium and large-sized organizations maintain multiple tools and solutions in parallel. This creates a fragmented reality where the answer to a business question lies distributed among them.

• Customer data is in Salesforce.

• Budget data is in Excel.

• Transactions are in an ERP system.

This is where the power of the Semantic Model shines. It acts as a central Hub in the middle, consolidating this data in one place, ready to serve the business.

What is a Semantic Model? (The Abstract View)

Before we talk about tools, let’s talk about the concept.

Technically, a semantic model is a copy of your data with defined relationships, collected from different sources. It is compressed to be incredibly space-efficient and operates in RAM (Random Access Memory) to be super fast. Conceptually, this is the classical BI architecture used among several enterprise tools, whether it be QlikView, Tableau, or Power BI.

The first thing to understand is the Data Model and its Relationships.

Initially, we should look at the data model in an abstract way, on the business level. For example, an organization will always have Products, Customers, and Sales. These are facts. For a moment, we do not care that Products are defined in SAP, and Customers and Sales are in Salesforce.

Having just these three business entities, we can already draw the schematic data model and define the relationships.

What do we mean by the lines connecting them? These represent Key Columns, like Customer ID or Product ID.

• Usually, all Customers in the Customer table have a unique Customer Key.

• The Sales table can contain thousands or millions of rows, documenting sales of different products to different customers during a defined period.

The Foundation: The Star Schema ⭐

When defining the logical data model, we should strive to achieve the Star Schema. It is the best compromise to achieve the best performance, storage efficiency, and query flexibility later on.

In a Star Schema, the tables of the semantic model fall into two categories:

1. Dimension Tables: These describe the “Who, What, Where.” They usually have a unique value column (like Customer ID or Product ID).

2. Fact Tables: (Sometimes called Transactional tables). These store the details about multiple business transactions (like Sales) and do not have unique columns.

Why is this called a Star Schema? Because the drawing looks like a star: one Fact table in the center, surrounded by many Dimension tables.

The “Architect’s View”: Top-Down Flow

In reality, the data model might be more complex. It might have two or more fact tables, like Sales and Budget.

So, I advise against thinking about the “Star” visualization too literally. A much better habit is to place Dimension tables at the top of your drawing, and Fact tables below.

The reason placing Dimensional tables at the top is better is because later, when we deal with the concept of Filter Directions, it will be much easier to visualize “Top-Down” flow scenarios. Understanding that filters flow downhill is crucial to understanding the model’s behavior.

The Alternative: Why Not One Big Table?

Just before leaving the concept of the Star Schema, let’s ask ourselves: what are the alternatives?

One alternative would be one large Flattened Table—like one giant Excel spreadsheet constructed with the help of XLOOKUP, containing data from Customers, Products, and Sales all in one row.

Technically, this is possible, but only as long as we have one fact table in the model (like Sales).

As soon as we introduce a second fact table—like Budget—the flat table approach breaks. You would need two separate flattened tables: one based on Sales and one based on Budgets.

• This introduces Data Redundancy, as data from Customers, Calendar, and Products is stored twice.

• This uses expensive RAM memory inefficiently.

One advantage of a flattened table is that it is extremely fast at querying time. However, I maintain that the Star Schema is the best compromise between speed, space, and scaling up flexibility.

The “Back-End”: The Importance of ETL

Now that we have covered the abstract layer of the semantic data model, we need to cover the importance of the ETL part.

ETL stands for Extract, Transform, Load.

For example, if the Customer Data resides in the Salesforce system, we need to extract that data into the semantic model. But we rarely want to load it “as is.” We want to apply Transformations first.

• Column Selection: We might select only the most important columns to save memory.

• Joins: We might join “Order Headers” and “Order Lines” tables to flatten them into a single transaction table.

• Quality Assurance: The ETL stage is the perfect time to clean errors and ensure data quality.

From my experience, the ETL part is the most important phase. This is where most of the investment value is kept.

From Abstract to Concrete: The Microsoft Stack 🛠️

So far, everything I have described—Star Schemas, ETL, Relationships—is universal. You apply these principles whether you use Qlik, Tableau, or SAP HANA.

But as a Microsoft Specialist, my tool of choice is Power BI.

In the Microsoft ecosystem, the “Semantic Model” is a specific artifact powered by the Vertex (formerly xVelocity) engine. It lives inside Power BI or Analysis Services (SSAS). And to make this model intelligent, we don’t use generic SQL; we use a specific, powerful language called DAX (Data Analysis Expressions).

This is where we move from “Theory” to “Implementation.”

The “Brain”: DAX Measures and Intelligence

At the center of our Power BI model, we have the relationships and the data. Now we add the components that make the model intelligent: Calculated Tables, Calculated Columns, and Measures.

• Calculated Tables: If there is a need, it is possible to add new tables to the model using DAX. A prime example is the Calendar table, which is mandatory for Time Intelligence calculations.

• Calculated Columns: Similarly, we can add new columns derived from existing data.

• Measures: Finally, we arrive at the most powerful concept in the Microsoft stack.

A Measure is like a formula residing on top of the semantic model. From a logical point of view, a measure should be seen as disconnected from any particular table. A measure is like a predefined unit of intelligence, delivering a specific answer from the semantic model.

• Measure 1: [Sales Amount] could calculate SUM(Sales[Qty] * Sales[Price]).

• Measure 2: [Sales Budget] could sum the budget table.

• Measure 3: [Sales vs. Budget] could calculate the variance by utilizing the previously defined measures.

The complexity and the value of measures can grow up to infinity.

The Payoff: Answering Business Questions

Finally, we have arrived at the Harvesting part.

So far, we have invested heavily: we did the ETL, we created relationships, and we defined DAX measures. Now, we are ready to ask the semantic model the real business questions.

• What are the top sold products this year?

• How is each product category doing compared to the budget per Region?

• How many returning customers did we get this year?

The number of business questions is unlimited. So, what are the tools to start asking these questions?

1. Reports and Visuals (The GUI) We can see the report and visuals (pivot tables, dashboards, or diagrams) as a GUI (Graphical User Interface) to send business questions to the semantic model and present the received answers visually. The report is interactive, not static. When users play with slicers, they are technically resending slightly modified questions to the semantic model and instantly seeing the response.

2. Beyond the Dashboard But the GUI report is not the only option. Because the logic lives in the Model, not the Report, we can use other client tools to send questions:

• Excel: Using Power Pivot Tables or DAX Table Expressions, connected to the model.

• Paginated Reports: For detailed lists.

• AI Agents: Using natural language to query the model on the fly.

Summary

Technically speaking, this semantic model lives inside Microsoft’s Analysis Services (SSAS) software. This software engine is running inside the Power BI Service, but you can also find it locally within Power BI Desktop, or even buried inside your local Excel installation.

Once the semantic model is published, and different client tools are defined, the only thing left to do is to schedule the periodic data refresh.

The report is temporary. The visuals are just the interface. The Semantic Model is the asset.

Architect’s Note: I wrote this article intentionally before reading Christian Wade’s recent post on the same topic, to ensure my architectural view remained unbiased.

It turns out we landed on very similar conclusions regarding the Semantic Model’s role as an accelerator. If you want to read the official Microsoft engineering perspective, I highly recommend his article here:

• Power BI semantic models as accelerators for AI-enabled consumption

Want to dive deeper? Browse the full library by category on the Topics Page.

Vilmantas Lialko is a Senior Solution Architect at TECHOICE.

Connect with me on LinkedIn: Vilmantas Lialko

Need help with Power BI architecture? Visit www.techoice.se to learn about our consulting services.

I am Vilmantas, a Senior Project Manager and Solution Architect.

I spend 100% of my time working with clients to solve complex data problems. I often see a gap between “textbook theory” and the messy reality of business data.

Why I started this blog I want to bridge that gap. Instead of theoretical tutorials, I will share the specific challenges I face on the job—and the solutions I build to fix them.

What you can expect Every week, I share a practical guide covering:

• Power BI Architecture: How to build models that scale.

• DAX & M: Solving specific calculation problems.

• Excel: Advanced techniques for when you can’t use Power BI.

• Project Management: How to bridge business strategy with technical execution.

Join the conversation If you are a data professional, a business analyst, or just someone trying to make sense of a SharePoint list, I invite you to subscribe. Let’s build better data solutions together.

Ready to dive deeper? Browse the full library by category on the Topics Page.