6.2 · Quick troubleshooting

Level 6 · In practice

6.2Quick troubleshooting

Goal: have a « symptom → causes → actions » playbook for common Power BI errors.
Estimated time: 12 min · If you only have 5 min: read “The essentials in 30s” + the diagram.

The essentials in 30 seconds

  • Diagnose: one symptom = likely causes = a sequence of actions — we don't fix at random.
  • Roots: relationships, types, date table, filter context, column vs measure, performance — 90% of blockers.
  • Verify: read the cell context, mark the date table, time in the Analyzer, prove on an edge case.

Zineb's thread — the table stuck beside the screen

Zineb keeps this table beside her screen in Algiers. Verdict after a quarter: three rows served her the most — totals identical on every row of a visual, prior-year revenue that stays blank, and a report that drags. For each, she ended up applying the sequence (symptom, causes, actions) instead of rewriting measures at random.

Symptom observed, causes verified, actions in order: the reflex holds in three steps.

One reflex per symptom

Most Power BI blockers are classics. Linking each symptom to its likely causes and to a sequence of actions saves precious time.

The context before the formula

A « weird » DAX result rarely comes from the formula alone: it's almost always a misunderstood filter context or an incomplete relationship. We observe, verify, then fix.

Optimize on evidence

For any slowness, we time it in the Performance Analyzer before touching the model: we optimize in the order model → measures → visuals.

SymptomLikely causesActions
Identical totals on every row of a visualmissing, broken or inactive relationship between the crossed tablesModel view: create or repair the relationship (1:* cardinality, single direction); check the key column
« Weird » DAX result or wrong at the totalmisunderstood filter context; average of ratios on the Total rowread the cell context; recalculate by iteration (SUMX); check CALCULATE and ALL
Prior-year revenue (or YTD) blank or wrongdate table not marked; relationship through the wrong column; history too shortmark as a date table; check the date relationship; check the history depth
Months sort out of order (April before January)alphabetical sort of the Month columnsort the Month column by a MonthNumber column (Sort by column)
My calculated column doesn't react to slicersa column is frozen at refresh; a measure was neededcreate a measure (recalculated on the fly according to the context) rather than a column
Slow report (several seconds per visual)unoptimized model, useless columns, too many visuals, auto date/timePerformance Analyzer; remove useless columns; disable the auto date/time hierarchy
Common misinterpretation: « the table replaces diagnosis ». No. The table gives likely causes, not a verdict: observe the symptom, verify the cause (relationships, context, date table, performance), then apply the targeted action.
Text version of the diagram (SEO / screen readers / translation): 1) Name the observed symptom (identical totals, DAX wrong at the total, blank prior year, disordered months, column mute to slicers, slowness). 2) Retain the likely causes from the table without concluding alone (missing relationship, filter context, date table, sort, column vs measure, performance). 3) Apply the actions in order (repair the relationship, SUMX, mark the date table, Sort by column, switch to a measure, Analyzer). 4) Fix at the root (the same symptom returning = a design to fix: model, relationships, measures). Lesson: an error that returns calls for a setting, not random rewrites.

Ready-to-say script — diagnosing without random rewrites (30s)

« My symptom: [identical totals / DAX wrong at the total / blank prior year / slow]. I check the likely cause in the table (relationship, context, date table, performance), I apply the targeted action and I prove it on an edge case. »

The reflex holds in three steps: symptom, cause, action.

Ready-to-say script — checking a measure's context (30s)

« My measure shows [an unexpected result]. I read the cell context out loud: which filters are active? I check the relationship and the date table, then I fix the cause, not the formula. »

Always verify the context before rewriting a measure.

Copy-paste template — DAX band-aids

Line Revenue = SUMX(Sales, Sales[Quantity] * Sales[UnitPrice])
Growth % = DIVIDE([Total Revenue] - [Revenue PY], [Revenue PY])
Revenue PY = CALCULATE([Total Revenue], SAMEPERIODLASTYEAR(Dates[Date]))
-- PY blank? Mark the date table and check the relationship.

Copy-paste template — safe fallback

Rank = RANKX(ALL(Products[Product]), [Total Revenue])
Line Average = SUMX(Sales, DIVIDE(Sales[Amount], Sales[Quantity]))
-- Check: 1:* relationship, marked date table, column vs measure.

SME / small budget

No formal table: one symptom, the likely cause, the action and who proves it, noted down.

SME Algiers

Integrate real exports into the diagnosis: local separator, FR dates, known reference person.

Remote / hybrid

Add a screenshot to the diagnosis: at a distance, a written symptom and proof avoid duplicates.

Intercultural

Make the findings explicit in writing: what seems obvious (which department, which format) is not for everyone.

Caution: Generic reminder: the same recurring error is not ten incidents — fix the design at the root (relationships, date table, measures) and keep a copy of the .pbix before any mass repair.

48h challenge — apply tomorrow

Spot 1 current symptom (identical totals, blank prior year, disordered months, slowness), apply the table row (named symptom + verified cause + targeted action) and prove it.

Section exit checklist
  • I can link a symptom to its likely causes.
  • I check relationships, context and date table before fixing.
  • I prove every fix (totals, edge case, Analyzer).
Self-assessment 1-5: diagnosis before fix?systematic proof after fix?
Check your understanding

Zineb sees the same totals on every row of a visual. Which reflex does the table apply?

💡

Reflex: diagnose the symptom, identify the cause, apply the targeted action — and time any slowness in the Analyzer before touching the model.