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!!
Thank you for your reply.
Maybe I'm missing something... If I understsood it correctly, you are suggesting to use slicers to choose the relevant measure to be used.
But what I need is actually to decide which measure to use based on the period type selected by the user.
So when a user selects any preset period, the precalculated measure will be used. And when "Custom" period is used in the period slicer, the non-precalculated measure will be used.
Hi karimm , Thank you for reaching out to the Microsoft Fabric Community Forum.
Calculation groups won’t change how DAX evaluates branches. They’re powerful for measure formatting and reuse but they don’t eliminate the eager evaluation you saw with IF/SWITCH. So, Copilot’s suggestion is misleading in this specific context.
What you actually need is a way for the period slicer itself to control which version of each KPI gets passed into visuals. Instead of bookmarks or inline IFs, you can model this as a mapping between the period type and the right measure. The slicer drives that mapping and only the mapped measure is ever executed.
This works because the measure isn’t conditionally branching inside DAX, the engine only sees the selected measure reference. That gives you the fast path when a preset is chosen and the flexible path when custom dates are used, with no maintenance overhead from bookmarks.
Hello
Thank you for the reply...
I understand what you are saying but can you please elaborate on the "how" to do what you suggested? Is it by field parameters? another mechanism?
Hi karimm , Thank you for reaching out to the Microsoft Fabric Community Forum.
Yes, the right approach is to use field parameters but instead of exposing them directly as a slicer, you tie them to the existing Period Type slicer (Preset vs Custom). Field parameters differ from IF/SWITCH because only the chosen measure is actually sent to the engine, so you don’t get the slow branch evaluated in the background.
Create a field parameter with both versions of your KPI (e.g. precalculated and custom), then build a simple mapping table that links Preset -> precalculated and Custom -> raw measure. Relate this table to the parameter table so that when users pick a period type, the parameter automatically resolves to the right measure.
The part where you link the period slicer to the parameter table is a design workaround, it may require a bit of model setup and depending on your exact schema you might need to adjust relationships or use a measure to enforce the mapping.