Category: Power BI

Mastering the SWITCH Function in Power BI DAX – includes usage and code examples

When building measures and calculated columns in Power BI, we often face situations where we need to evaluate multiple possible outcomes and return different results based on conditions. While IF statements can handle this, they can become cumbersome, confusing, and hard to read when there are many branches.

The SWITCH function in DAX is a cleaner, more efficient alternative for handling multiple condition checks. Let’s take a look.

SWITCH Function Signature

The basic DAX syntax of the SWITCH function is:

SWITCH(<expression>,
       <value1>, <result1>,
       <value2>, <result2>,
       ...,
       [<else>])
  • <expression> – The value or expression you want to evaluate once.
  • <valueN> – A possible value that the expression could equal.
  • <resultN> – The result to return if the expression equals the corresponding <valueN>.
  • [<else>] – (Optional) The default result if none of the value-result pairs match.

Note: the <expression> is evaluated once and compared against multiple <value> options in sequence until a match is found.

Example 1 – Basic SWITCH Usage

Suppose we have a Customer[Category] column containing numeric codes:

  • 1 = “Bronze”
  • 2 = “Silver”
  • 3 = “Gold”

We can translate these codes into readable labels using SWITCH as in the following DAX code example:

Customer Category Label =
SWITCH(Customer[Category],
       1, "Bronze",
       2, "Silver",
       3, "Gold",
       "Unknown"
      )

Explanation:
– The Customer[Category] column is evaluated once.
– If it equals 1, "Bronze" is returned; if 2, "Silver"; if 3, "Gold".
– Otherwise, "Unknown" is returned.

Example 2 – Multiple Match Checks

If we wanted to calculate a commission rate based on a sales tier:

Commission Rate =
SWITCH(Sales[SalesTier],
       "Low", 0.02,
       "Medium", 0.05,
       "High", 0.08,
       0
)

Explanation:
– The Sales[SalesTier] column is evaluated once.
– If it equals "Low", 0.02 is returned; if "Medium", 0.05; if "High", 0.08.
– Otherwise, 0 is returned.

The SWITCH TRUE Pattern

This is a really cool and handy usage of the function. Sometimes, we don’t have a single value to compare against. Instead, we want to evaluate different logical conditions. In these cases, we can use the SWITCH TRUE pattern, which works like multiple IF statements but is much cleaner.

DAX Syntax:

SWITCH( TRUE(),
<condition1>, <result1>,
<condition2>, <result2>,
...,
[<else>])

Here, TRUE() acts as the <expression>. Each <condition> is a Boolean expression that returns TRUE or FALSE. The function returns the corresponding result of the first condition that evaluates to TRUE.

Example 3 – SWITCH TRUE for Ranges

Suppose we want to grade students based on their score:

Grade =
SWITCH(TRUE(),
Scores[Score] >= 90, "A",
Scores[Score] >= 80, "B",
Scores[Score] >= 70, "C",
Scores[Score] >= 60, "D",
"F"
)

Explanation:
– Each Scores[Score] comparison statement is evaluated in order from top to bottom, and returns the first match.
– If Scores[Score] >= 90, “A” is returned; if Scores[Score] >= 80, “B”; if Scores[Score] >= 70, “C”, if Scores[Score] >= 60, “D”
– Otherwise, “F” is returned.

Note: Other more complex conditions, such as ones using OR and AND logic or including complex calculations, can be used.

Why SWITCH is such a great, clean, easy to use function:

  • No nested IFs.
  • Each condition is independent.
  • Easy to add or modify conditions.

When to Use SWITCH Instead of IF

While IF can achieve the same results, SWITCH has several advantages:

  1. ReadabilitySWITCH structures conditions in a clear, top-to-bottom list.
  2. Maintainability – Easier to add, remove, or change cases without dealing with messy nested parentheses.
  3. Performance – In some cases, SWITCH can be more efficient because the expression (in the basic form) is evaluated once, not multiple times as with nested IF statements.
  4. Logical Branching – The SWITCH TRUE pattern handles complex conditions without deep nesting.

Example 4 – IF vs. SWITCH

Let’s take a look at a comparison example:

IF Version:
Category Label =
IF(Customer[Category] = 1, "Bronze",
IF(Customer[Category] = 2, "Silver",
IF(Customer[Category] = 3, "Gold", "Unknown")
)
)

SWITCH Version:
Category Label =
SWITCH(Customer[Category],
1, "Bronze",
2, "Silver",
3, "Gold",
"Unknown"
)

Result: As you can see, the SWITCH version is shorter, easier to read, less error-prone, and easier to maintain.

Key Takeaways

  • Use basic SWITCH when comparing one expression to multiple possible values.
  • Use SWITCH TRUE when checking multiple conditions or ranges.
  • SWITCH often results in cleaner, more maintainable DAX than deeply nested IF statements.
  • Always include a default (else) value to handle unexpected cases.

Thanks for reading and I hope you found this useful.

Calculated Columns vs. Measures in Power BI: Understanding the Differences

When working in Power BI, two common ways to add custom calculations to your data model are calculated columns and measures. While they both use DAX (Data Analysis Expressions), their purposes, storage, and performance implications differ significantly. Understanding these differences can help you design more efficient and maintainable Power BI reports.

1. What They Are

Calculated Column
A calculated column is a new column added to a table in your data model. It is calculated row-by-row based on the existing data and stored in the model like any other column.

Measure
A measure is a calculation that is evaluated on the fly, usually aggregated at the visual level. Measures don’t exist as stored data in your table—they are computed dynamically based on filter context.

To create a Calculated Column or a Measure, either from the Home menu …

… or from the Table Tools menu …

… select “New Column” (to create a Calculated Column) or “New Measure” (to create a new measure). Then enter the relevant DAX for the column or measure as shown in the next section below.

2. DAX Syntax Examples

Imagine a Sales table with columns: Product, Quantity, and Unit Price.

Calculated Column Example
Creating a calculated column:
Total Price = Sales[Quantity] * Sales[Unit Price]

This new column will appear in the table and will be stored for every row in the Sales table.

Measure Example
Creating a measure:
Total Sales = SUMX(Sales, Sales[Quantity] * Sales[Unit Price])

This measure calculates the total across all rows in the current filter context—without physically storing a column for every row.

3. When They Are Computed

FeatureCalculated ColumnMeasure
When computedDuring data model processing (data refresh).At query time (when a visual or query is run).
Where storedIn-memory within the data model (VertiPaq storage).Not stored—calculated on demand.
Performance impactIncreases model size (RAM & disk space).Consumes CPU at query time, minimal storage overhead.

4. Storage and Performance Implications

  • Calculated Columns
    • RAM & Disk Space: Stored in VertiPaq compression format. Large columns increase your .pbix file size and memory footprint.
    • CPU: Low impact at query time since results are precomputed, but refresh time increases.
    • Good for: Fields you need for filtering, sorting, or joining tables.
  • Measures
    • RAM & Disk Space: No significant impact on storage since they’re not persisted.
    • CPU: Can be CPU-intensive if the calculation is complex and used across large datasets.
    • Good for: Aggregations, KPIs, and calculations that change based on slicers or filters.

5. When to Use Each

When to Use a Calculated Column

  • You need a field for row-level filtering or grouping in visuals.
  • You need a column to create relationships between tables.
  • The calculation is row-specific and independent of report filters.

Example:

Sales Category = IF(Sales[Quantity] > 100, "High Volume", "Low Volume")

When to Use a Measure

  • You want calculations that respond dynamically to slicers and filters.
  • You want to avoid inflating your data model with unnecessary stored columns.
  • The calculation is aggregate-based.

Example:

Average Order Value = DIVIDE([Total Sales], DISTINCTCOUNT(Sales[Order ID]))

6. When They Cannot Be Used

SituationCalculated ColumnMeasure
Relationship creation✅ Can be used❌ Cannot be used
Row-level filtering in slicers✅ Can be used❌ Cannot be used
Dynamic response to slicers❌ Cannot recalculate✅ Fully dynamic
Reduce model size❌ Adds storage✅ No storage impact

7. Summary Table

FeatureCalculated ColumnMeasure
Stored in modelYesNo
Calculated atData refreshQuery time
Memory impactHigher (stored per row)Minimal
Disk size impactHigherMinimal
Dynamic filtersNoYes
Best forFiltering, relationships, sortingAggregations, KPIs, dynamic calcs

8. Best Practices

  • Default to measures when possible—they’re lighter and more flexible.
  • Use calculated columns sparingly, only when the calculation must exist at the row level in the data model.
  • If a calculated column is only used in visuals, try converting it to a measure to save memory.
  • Be mindful of CPU impact for very complex measures—optimize DAX to avoid performance bottlenecks.

I hope this was helpful in clarifying the differences between Calculated Columns and Measures, and will help you to determine which you need in various scenarios for your Power BI solutions.

Thanks for reading!

Understanding UNION, INTERSECT, and EXCEPT in Power BI DAX

When working with data in Power BI, it’s common to need to combine, compare, or filter tables based on their rows. DAX provides three powerful table / set functions for this: UNION, INTERSECT, and EXCEPT.

These functions are especially useful in advanced calculations, comparative analysis, and custom table creation in reports. If you have used these functions in SQL, the concepts here will be familiar.

Sample Dataset

We’ll use the following two tables throughout our examples:

Table: Sales_2024

The above table (Sales_2024) was created using the following DAX code utilizing the DATATABLE function (or you could enter the data directly using the Enter Data feature in Power BI):

Table: Sales_2025

The above table (Sales_2025) was created using the following DAX code utilizing the DATATABLE function (or you could enter the data directly using the Enter Data feature in Power BI):

Now that we have our two test tables, we can now use them to explore the 3 table / set functions – Union, Intersect, and Except.

1. UNION – Combine Rows from Multiple Tables

The UNION function returns all rows from both tables, including duplicates. It requires the same number of columns and compatible data types in corresponding columns in the the tables being UNION’ed. The column names do not have to match, but the number of columns and datatypes need to match.

DAX Syntax:

UNION(<Table1>, <Table2>)

For our example, here is the syntax and resulting dataset:

UnionTable = UNION(Sales_2024, Sales_2025)

As you can see, the UNION returns all rows from both tables, including duplicates.

If you were to reverse the order of the tables (in the function call), the result remains the same (as shown below):

To remove duplicates, you can wrap the UNION inside a DISTINCT() function call, as shown below:

2. INTERSECT – Returns Rows Present in Both Tables

The INTERSECT function returns only the rows that appear in both tables (based on exact matches across all columns).

DAX Syntax:

INTERSECT(<Table1>, <Table2>)

For our example, here is the syntax and resulting dataset:

IntersectTable = INTERSECT(Sales_2024, Sales_2025)

Only the rows in Sales_2024 that are also found in Sales_2025 are returned.

If you were to reverse the order of the tables, you would get the following result:

IntersectTableReverse = INTERSECT(Sales_2025, Sales_2024)

In this case, it returns only the rows in Sales_2025 that are also found in Sales_2024. Since the record with “D – West – $180” exists twice in Sales_2025, and also exists in Sales_2024, then both records are returned. So, while it might not be relevant for all datasets, order does matter when using INTERSECT.

3. EXCEPT – Returns Rows in One Table but Not the Other

The EXCEPT function returns rows from the first table that do not exist in the second.

DAX Syntax:

EXCEPT(<Table1>, <Table2>)

For our example, here is the syntax and resulting dataset:

ExceptTable = EXCEPT(Sales_2024, Sales_2025)

Only the rows in Sales_2024 that are not in Sales_2025 are returned.

If you were to reverse the order of the tables, you would get the following result:

ExceptTableReverse = EXCEPT(Sales_2025, Sales_2024)

Only the rows in Sales_2025 that are not in Sales_2024 are returned. Therefore, as you have seen, since it pulls data from the first table that does not exist in the second, order does matter when using EXCEPT.

Comparison table summarizing the 3 functions:

FunctionUNIONINTERSECTEXCEPT
Purpose & OutputReturns all rows from both tablesReturns rows that appear in both tables (i.e., rows that match across all columns in both tables)Returns rows from the first table that do not exist in the second
Match CriteriaColumn position (number of columns) and datatypesColumn position (number of columns) and datatypes and valuesColumn position (number of columns) and datatypes must match and values must not match
Order Sensitivityorder does not matterorder matters if you want duplicates returned when they exist in the first tableorder matters
Duplicate HandlingKeeps duplicates. They can be removed by using DISTINCT()Returns duplicates only if they exist in the first tableReturns duplicates only if they exist in the first table

Additional Notes for your consideration:

  • Column Names: Only the column names from the first table are kept; the second table’s columns must match in count and data type.
  • Performance: On large datasets, these functions can be expensive, so you should consider filtering the data before using them.
  • Case Sensitivity: String comparisons are generally case-insensitive in DAX.
  • Real-World Use Cases:
    • UNION – Combining a historical dataset and a current dataset for analysis.
    • INTERSECT – Finding products sold in both years.
    • EXCEPT – Identifying products discontinued or newly introduced.

Thanks for reading!

How to enter data using DAX DATATABLE function in Power BI

I previously posted an article about how to manually enter data into Power BI using the Enter Data feature. That article can be found here: https://thedatacommunity.org/2024/08/03/how-to-enter-data-manually-and-update-it-in-power-bi/. This post shares how to use DAX to create a table with data in Power BI, an alternative way of creating data manually, which can be useful in many scenarios.

In Power BI Desktop, from the Table tools menu, click New Table:

Enter the code for the new table and data as shown in the example below:

The example code below shows the syntax for the DATATABLE function. You need to specify the table name (the name in the example below is “Games Table created using DAX”), and column names and their corresponding datatypes, and then provide the data as a list of values within braces to represent each row of data. STRING values are enclosed in quotes as usual.

Then click the checkmark to run the code/create the table with data.

When you review the table in the Table View, it will look like this, just like other tables look:

This table and data can then be used as any other table and data loaded into Power BI.

Thanks for reading. I hope you found this useful.

Why can’t I add search to my Power BI slicer?

Power BI makes it really easy to add the search capability to slicers to allow users to search for values. This is especially useful when there are many values available in the slicer. However, you might be wondering, “Why don’t I see the Search option on my slicer?” or ‘How can I add the Search option to my slicer since it’s not showing in the options?”

Unfortunately, this feature is not available on numeric or date slicers.

To access and activate (or deactivate) the search feature on a slicer, hover over the slicer, and then click the “3-dots” icon in the top right.

If the slicer contains text values, you will see the following options, from which you can simply click “Search” to activate the feature:

When it is “checked” as shown above, it’s activated, and it’s deactivated when not “checked”.

However, if the slicer contains date or number values, you will see the following options, which do not include the “Search” option:

A very ugly option is to set your slicer settings Style to “Between”, and then a user would be able to enter the same value in both the From and To values to find the specific value. Obviously, this is not ideal and will not be desirable in most cases, but it is an option for some cases, and maybe useful during testing.

Good luck on your data journey!

Errors loading data from Excel into Power BI

While loading some data from several Excel files into Power BI, I encountered the following errors:

Table1:
“Load was cancelled by an error in loading a previous table.”

Table2:
“OLE DB or ODBC error: [Expression.Error] The key didn’t match any rows in the table.”

Table3:
“A single value for column ‘Area of Responsibility’ in table ‘Requisitions-Load’ cannot be determined. This can happen when a measure formula refers to a column that contains many values without specifying an aggregation such as min, max, count, or sum to get a single result.”

As you know (since you are reading this post), these error messages are not very specific.  I did not immediately find anything obviously wrong.  After reading a couple posts, I checked the latest data files to see if there were any new, missing, or incorrect column names or sheet names.

Turns out, one of the files did not have the expected Sheet name. After updating the sheet name to the correct name, all the files loaded without an issue.

I hope this helped.

Why can’t I download my report from Power BI Service to a pbix file?

You might be attempting to download a report from the Power BI Service to a pbix file and do not see that option or that option is not active or selectable. The reason you cannot select the option is most likely because the report was created in the Power BI Service as opposed to using the Power BI Desktop.

When a report is created in the Power BI Service, you are not able to download that report to a Power BI pbix file. That option is only available when you create the report using the Power BI Desktop and then publish it to the Power BI Service.

Thanks for reading!

Activating or Deactivating “Preview Features” in Power BI

Microsoft frequently adds new features that are available for preview in Power BI. This is a way for Microsoft to launch the features and have them tested by the community before making them fully available in the Power BI application. These features are sometimes in preview mode for a long time, and you may find that you want to use one or more of these features before they become generally available.

To activate (or deactivate) preview features, go to … File –> Options and settings –> Options

Then, in the Options window, select “Preview features” (on the left) as shown below.

Then, select the options you would like to activate or deactivate on the right side, such as checking “Shape map visual” to activate it or unchecking “Sparklines” to deactivate it. Once you have selected or unselected all the features you want, then click “OK”. Then, make sure to save whatever you need to, and then close and reopen Power BI for the activations or deactivations to take effect.

Thanks for reading.

Add a “Last Refreshed Date” notification on a Power BI dashboard

It is customary to add a “Last Refreshed Date” to dashboards to notify users of when the dashboard was last refreshed. Here will go through the steps of adding a “Last Refreshed Date” to a Power BI dashboard.

Open the dashboard you want to add the notification to in Power BI Desktop, and then Get Date -> Blank Query. Name the new query as “Last Refreshed Date” or something like that.

Then, set the value as shown below, by typing “= DateTime.LocalNow()” into the formula area:

Next, convert the value to a Table by clicking the “To Table” icon, and then clicking the “To table” option:

A table with the single date column is created

Set the data type as Date/Time …

… and rename the column to something meaningful, such as “Last Refreshed Date” …

Close and apply your changes.

The table will be added to your Power BI model. It should have no relationships.

Now, add a Card visual to your dashboard, place it where it is visible but out of the way, such as in the top-right or bottom-right corner, and add the Last Refreshed Date column to it from the new table. Now, whenever your dashboard is refreshed, this new table and visual will also be updated/refreshed.

Thanks for reading!

Transpose vs. Pivot vs. Unpivot in Power BI

In this post, I will quickly show how to perform 3 key transformations in Power BI – Transpose, Pivot, and Unpivot – and what impact they have on the data they are applied to. These transformations are often needed to manipulate the original data to get it into the shape needed to create the Power BI model and reports. We will use a simple example so that you can see clearly the effect of each transformation.

This is the original dataset – Student Grades:

Transpose

Transpose the data by going to the Transform ribbon and clicking “Transpose”.

This is what the data looks like after the Transpose transformation is applied. The rows are converted into columns, and the columns are converted into rows. Default headers / column names are applied.

Pivot Column

Starting with the original dataset, we will now Pivot the dataset. Go to Transform ribbon, click on “Pivot Column”.

The Pivot Column dialog opens. As noted, it will use the values in the Names column to create new columns, and will use the Score column as the Values Column.

This is what the data looks like after Pivot is applied as described above. Pivot Column converts the selected Name column values into column headers.

Unpivot Columns

Starting with the original dataset, we will now Unpivot the dataset. First select all 4 name columns by using “Ctrl + Click”.

Then, go to Transform ribbon, click on “Unpivot Columns”. This is what the data looks like after the Unpivot Columns transformation is applied. Unpivot Columns converts the selected columns (the name columns in this case) into a column of values (Attribute) and the column values are stored in the Value column.

Thanks for reading!