Forum Discussion
Calculation groups to replace slow IF/SWITCH?
Hi karimm , Thank you for reaching out to the Microsoft Fabric Community Forum.
You’re right, even when Preset is selected, Power BI’s query engine still ends up touching the expressions behind the slow measure, so you don’t get the fast-only path. Field parameters and calculation groups change how you organize/switch measures, not how the DAX engine chooses what to evaluate, so they won’t reliably prevent the other branch from being computed.
The reason your bookmark setup performs best is simple: bookmarks physically hide the visuals that reference the heavy measures. When visuals aren’t rendered, Power BI doesn’t query their measures at all, meaning only the fast queries run. That’s why you’re seeing consistent, predictable performance there.
If you want to remove bookmark maintenance while keeping the same speed, the only real fix is at the model level. Build a pre-aggregated table for your preset date ranges and configure Manage Aggregations (or a composite model). That way, Power BI automatically routes preset queries to the aggregated table and only uses raw data for true custom ranges, no branching logic or bookmarks needed.
Create calculation groups in Power BI - Power BI | Microsoft Learn
Calculation groups in Analysis Services tabular models | Microsoft Learn
User-defined aggregations - Power BI | Microsoft Learn
Use report readers to change visuals - Power BI | Microsoft Learn
Short answer: calculation groups won’t magically stop the “other” branch from being computed. DAX can evaluate both sides of IF/SWITCH depending on dependencies, so you can still pay the slow cost. Using a calc group doesn’t change that.
Use a Measure Field Parameter (not bookmarks, not IF/SWITCH):
-
Create a measure parameter with two entries per KPI:
• [Builds_Triggered_precalculated]
• [Builds_Triggered_custom]
Power BI will generate a parameter table and a slicer.
-
Put the generated parameter field in your visuals’ Values.
-
Use the parameter slicer (or sync it across pages) to choose Preset vs Custom.
Why this works: the query only includes the selected measure, so the other measure is not evaluated at all → you get the fast path when “Preset” is chosen, with no bookmark maintenance.
Tip: Do the same for all KPIs (each parameter can include pairs of measures), or create one parameter per KPI group if you need different slicers.
If this post helps, please consider accepting it as the solution to help the other members find it more quickly.
Appreciate your Kudos!!