Mise en place for DAX: measure or calculated column?

Twenty years in hospitality taught me one distinction that holds in any professional kitchen: some prep has to happen hours before service, because it needs time to bind, to rest, to become what it needs to be. Other things you can only do at the last moment. A steak cooked and plated two hours early is not a steak anymore by the time it reaches the table; whipped cream set aside an hour ago has already collapsed. Two categories of work, both essential, both part of mise en place in the broader sense: getting things ready for the moment they are needed. The moment just differs.

DAX works the same way. Some calculations belong at model refresh: computed once, stored, ready and waiting. Others can only happen at the moment a user interacts with the report, under whatever filter context that moment carries. Those two categories are the calculated column and the measure, and which is which is exactly where almost every beginner stalls on day two of a DAX course.

Why the wrong choice feels right

The pull toward a calculated column is understandable. You write your formula, press enter, and the value appears immediately in the table, row by row. That feels like progress. You can see what you made.

The problem is that a calculated column actually works that way: it evaluates per row and does not see the table as a whole. Ask it for a total, a margin across a selection, or a share of the visible set, and it only looks at its own row. The number it returns is not the number the user expects in the visual. That mismatch is one of the most common sources of DAX confusion, and it comes from placing a filter-aware calculation in a column instead of a measure.

Calculated column: ready at refresh

A calculated column is evaluated during data refresh or model load, one row at a time, in row context. The result is stored in the semantic model and occupies memory. The value stays fixed until the next refresh, the same for every user who opens the report.

Use a calculated column when you need a per-row value that will later serve as a filter, a category, or a relationship key. Customer segment based on revenue: the column evaluates each row’s revenue and assigns a label, ready for a slicer. Age bracket based on date of birth: computed at refresh so a slicer can bind to it. Year tier based on order date: same logic. If the column is not there at refresh, a slicer has nothing to bind to and a relationship has nothing to join on.

The mise en place comparison holds here exactly: it is ready before service starts, the same value for everyone, for the whole day.

Measure: computed at the moment of the question

A measure is not stored anywhere. It lives as a formula in the model, and it is evaluated fresh each time a user renders a visual, moves a slicer, or drills into a category. Under the filter context of that exact moment: the selected region, the active year in the slicer, the chosen product group.

Total in the current selection, margin in the chosen year, share of the visible set: these are questions that change with every user interaction. That is why aggregations (SUM, AVERAGE, COUNTROWS) always belong in measures. You can put them in a calculated column, but you will not get what you expect, because the column evaluates row by row without seeing the full table.

The question that makes the choice easy

The deciding question is straightforward: at what point does this calculation need to give an answer? At refresh, as a fixed per-row value that filters or categorizes? Calculated column. At the moment someone views the report, as an aggregate that moves with the selection? Measure. Ask that question out loud before you start typing, and the right choice becomes obvious almost every time. Models built this way are lighter and give reliable totals: two properties that seem abstract until the day they break.

Practise the timing question below: six calculations from daily work, and for each card you pick the moment it belongs to.

Next in the DAX basics series: SUM, COUNTROWS, and DISTINCTCOUNT, the three functions everyone knows and half of them are not doing what you think.

Want to work through the DAX basics together or talk through your own questions? Visit trainerbjorn.nl.