Where Power BI work actually happens

Four surfaces, four jobs

Power BI is not one tool. Confusing its parts is the first thing that makes reports hard to fix.

• Power Query — connects to sources and *reshapes* data before it lands. Runs on refresh.
• The model — tables and the relationships between them. This is the part that decides whether your numbers are right.
• DAX — the formula language that calculates over the model *at the moment a user clicks*.
• The report canvas — visuals. The thinnest layer, and the one people wrongly spend most time on.

The order matters and it is not negotiable. Reshaping belongs in Power Query, not DAX. Business logic belongs in the model, not in a visual's filters. Every hour spent moving work to its correct layer saves several later.

The golden rule of transformation

Do it as far upstream as you can. If the source system can supply a clean column, ask for it. If not, do it in Power Query. Only reach for DAX when the calculation genuinely depends on what the user has selected.

Why: Power Query transformations happen once, on refresh, and are then free at query time. A DAX calculated column that could have been a Power Query step is computed and stored for every row of your table, bloating the model and slowing every interaction — permanently, for a one-off job.

The running example

Throughout this course we build against a retailer:

| Table | Grain — one row per… | |---|---| | Sales | line on a receipt | | Returns | returned line | | Stores | store | | Products | product | | Calendar | day |

Grain — what one row *means* — is the single most useful word in this course. Most broken reports are a grain misunderstanding wearing a costume.

---

Check your understanding. A colleague has written a DAX calculated column that trims whitespace from product names. Which layer should that work have happened in, and what does leaving it in DAX cost?