Calculation groups that survive the next time-intelligence request
The 40-measure time-intel wall (Sales, Sales PY, Sales YoY, Sales YoY %, repeat for Margin, Units, Forecast…) is a maintenance tax. A calculation group applies those time patterns to SELECTEDMEASURE() once.
What belongs in the group
Put time and number-format patterns in the calculation group:
- Current, PY, YoY, YoY %, YTD, PYTD, YTD vs PYTD
- Optional: actual vs forecast, actual vs budget — if the comparison is a filter on a scenario table, not a different grain
Do not put business definitions (Net Revenue, Gross Margin %) in the calculation group. Those stay as explicit measures. The group is a lens, not a metric catalog.
Implementation rules that stick
- One group for time intel on the golden model. Name it
Time intelligence(or your locale equivalent), notCalc1 - Precedence documented. If you add a second group (e.g. currency), write the order down in the model description
- Format strings on the items that are percentages. Do not hope the base measure format survives
- Build in Tabular Editor or TMDL. Desktop’s UI is not where you want to maintain this
- Test with three measures: a simple SUM, a ratio, a time-intel-already-baked measure (the last one should not be used with the group)
Field parameters vs calculation groups
Field parameters swap which measure is in the visual. Calculation groups swap which calculation is applied. Using both on the same visual is legal and easy to get wrong.
Pattern that works: field parameter chooses Sales vs Margin; calculation group chooses Current vs YoY. Do not also put YoY inside the field parameter. Two sources of YoY is how execs get two numbers.
Rollout
Dev model first. One exec report page as the canary. Hide the calculation group column from report view until authors are briefed — otherwise someone drops it as a slicer next to a date slicer and files a ticket.
Killing duplicated YoY measures on a crowded model? Book a 30-minute call.