4.1.5. Visual Calculations

💡 First Principle: Some calculations are about the visual itself, not the business: a running total down the rows of this table, the difference from the previous column, a moving average across the points of this chart. Visual calculations compute directly on the visual's aggregated data, so they're simpler to write than model measures that must reconstruct the visual's structure in DAX.

A visual calculation is a DAX calculation defined on and stored with a single visual. Select a visual and choose New visual calculation (Home ribbon or the visual's context menu) to open the visual calculation editor, which shows the visual matrix: the rows and columns of aggregated values the visual already contains. Calculations reference fields in the visual by name and operate on that matrix after aggregation.

Visual calculation functions and templates include:

• RUNNINGSUM([Sales]): cumulative total along the axis.
• MOVINGAVERAGE([Sales], 3): average over a sliding window.
• PREVIOUS([Sales]), NEXT, FIRST, LAST: reference other positions, as in [Sales] - PREVIOUS([Sales]) for period-over-period change.
• COLLAPSE([Sales], ROWS) and EXPAND: move up or down the hierarchy, used for percent of parent: DIVIDE([Sales], COLLAPSE([Sales], ROWS)).
• COLLAPSEALL for percent of grand total; RANGE for custom windows.
• Templates for running sum, moving average, percent of parent, percent of grand total, average of children, versus previous, versus next, versus first, and versus last.

An axis parameter (ROWS, COLUMNS, ROWS COLUMNS, COLUMNS ROWS) controls the direction of calculation in matrices, and reset behavior controls where running calculations restart (for example, at each year).

Trade-offs: visual calculations are simpler and often faster for visual-specific math, and they can be hidden (used only as inputs to other calculations or formatting) while remaining in the visual. But they can't be reused by other visuals or reports, don't exist in the semantic model, and depend on the fields present in the visual. Business definitions that many reports need (Revenue, Margin %, YTD) belong in model measures; presentation logic for one visual (running total down this table) fits visual calculations.

⚠️ Exam Trap: If a requirement says the calculation "must be available to other report authors connected to the shared semantic model," a visual calculation is wrong because it lives only on one visual. Use a model measure (or a calculation group) instead.

Reflection Question: Writing a running total as a model measure requires CALCULATE with a date filter; as a visual calculation it's one function. Explain why the visual calculation is simpler, and what you give up by choosing it.