Power BI DAX Query View: Debugging Incorrect Plant-Level KPIs Before the Boardroom

A plant manager flags that Line 3’s OEE on the dashboard looks too high, or the yield number does not match what the floor saw. The instinct is to open the report, look at the visual, and try to reason backwards about what might be wrong. That is guessing, because a visual is the end of a chain — the measure, the filters applied by slicers and the page, the relationships in the model — and you cannot see which link is faulty by looking at the output.

The result is the familiar debugging loop: change something, refresh, see if the number moved, repeat. It is slow and it is not deterministic — you might make the number look right without understanding why, which is worse than leaving it wrong.

The DAX query view changes this from guessing to interrogating. It lets you ask the model directly for the number, and then take the calculation apart until you can see exactly where it diverges from what it should be — before the figure reaches a review where someone acts on it.

The first move is to get the number out of the visual and into a query. In the DAX query view, write a query that evaluates the suspect measure for the specific context in question — OEE for Line 3, last shift — and read the raw value directly. No visual, no page filters you cannot see; just the measure and the filters you explicitly set in the query.

This immediately separates two possibilities: is the measure itself returning the wrong number, or is the visual applying a filter you did not expect? If the query returns the correct value for Line 3 and the visual does not, the problem is in the report’s filter context, not the measure. If the query returns the same wrong value, the problem is in the measure or the model, and you keep digging there.

That split is most of the battle. A huge share of "the KPI is wrong" issues are actually filter-context issues — a slicer, a cross-filter, a page-level filter silently narrowing the data — and isolating the measure in a clean query tells you in one step whether you are chasing the measure or the report.

If the measure itself is wrong, take it apart. A composite KPI like OEE is availability times performance times quality; yield is good units over total units. In the query view, evaluate each component separately — the numerator, the denominator, each factor — and compare against what each should be. The error is almost always in one specific part, and evaluating them in isolation finds it fast.

Define intermediate expressions in the query to expose the working: show the total units and the good units next to the yield, or availability and performance next to OEE, for the plant and shift in question. Seeing the parts makes the fault obvious in a way the single rolled-up number never does — a denominator that is too large because it is not filtered to the shift, a factor that double-counts.

This is the manufacturing version of testing against known answers: you know roughly what availability or good-unit count should be for that line and shift from the floor, so when the decomposed query shows a component that is clearly off, you have found the fault rather than guessed at it.

Many plant-KPI errors come down to filter context — what rows the measure is actually evaluating over. A measure that looks correct can return the wrong number because the relationship between the production table and the line or shift dimension does not propagate the filter as expected, so "Line 3" does not actually narrow the data to Line 3.

In the query view you test this directly: evaluate the measure with an explicit filter to the plant, line and shift, and see whether the number responds correctly. If adding the filter in the query fixes it, the model’s relationships or the measure’s handling of context is the culprit — a relationship in the wrong direction, a measure that overrides context when it should respect it, a dimension not connected where the KPI assumes it is.

This is exactly the class of error that is invisible in a visual and obvious in a query. The visual shows a number; the query shows the number plus the ability to vary the context and watch how it responds, which is what reveals a measure that is not honouring the plant or shift it is supposed to.

The DAX query view turns plant-KPI debugging from a guessing loop into a deterministic investigation: isolate the measure in a clean query to separate measure errors from filter-context errors, decompose a composite KPI into its parts to find which one is wrong, and vary the filter context to catch a measure that does not respect the plant or shift. Each step narrows the fault until you can see it, and fix it knowing why.

The reason this matters is timing. A plant-level KPI that is wrong and reaches a leadership review gets acted on — a line gets praised or blamed on a false number, a decision is made on a figure the floor already knew was off. Finding the error in the query view, before the review, is the difference between a quiet fix and a decision made on bad data. The same discipline that tests a model before deployment applies here when one slips through: interrogate the number directly, do not stare at the chart.