10 Common Power BI Mistakes That Make Your Reports Wrong and Slow

Your Power BI report looks correct. The visuals are clean. The stakeholder approved the design. You publish it.

Three weeks later, someone spots a number that doesn't match. Or the report takes 45 seconds to load. Or your measure returns different results depending on which slicer is selected — and not in the way you intended.

None of these problems announce themselves while you're building. They surface quietly, in production, in front of the wrong audience.

This post documents the 10 mistakes that cause these failures — with explanations of why they happen and exactly how to fix them.

---

Why This Matters

Power BI is accessible enough that analysts can build reports without formal training. That accessibility is also why these mistakes are so common — the tool doesn't stop you from doing the wrong thing. It lets you do it, and shows you results that look plausible.

Wrong numbers that look right are more dangerous than errors that crash. These 10 mistakes all produce results that look reasonable until someone checks them carefully.

---

Core Content: 10 Mistakes, Diagnosed and Fixed

---

Mistake 1: Putting Business Logic in Power Query Instead of DAX

What it looks like: You create a calculated column in Power Query (M) for Revenue: = [Quantity] * [Unit Price]. It works. The column shows correct values. You use it in your reports.

Why it's a problem: Calculated columns in Power Query are static — they're computed once at refresh time, using only row-level values. They cannot respond to filter context. If a user selects a region, date range, or product category, your "Revenue" column stays the same. It doesn't dynamically aggregate based on the user's selection — only a DAX measure does that.

The deeper issue: When you SUM a column computed in Power Query, you get the sum of pre-calculated values — which may look correct but is actually inflated or incorrect in filtered contexts, especially with complex models.

Fix: Use Power Query to clean and prepare data. Use DAX measures for any business logic that should respond to filters. Revenue = SUMX(Sales, Sales[Quantity] * Sales[Unit Price]) as a measure is the right approach.

---

Mistake 2: Using Calculated Columns for What Measures Should Handle

What it looks like: You create a calculated column Profit Margin = [Profit] / [Revenue] on the fact table. The column stores a value per row. You then average or aggregate it in a visual.

Why it's a problem:

1. Calculated columns increase model size — they're stored for every row
2. Averaging a ratio across rows gives the wrong result (simple average vs. weighted average)
3. The column can't adapt to aggregation level — it calculates at the row grain, not the visual grain

Example of wrong result:

• Row 1: Sales = 100, Profit = 20, Margin = 20%
• Row 2: Sales = 900, Profit = 90, Margin = 10%
• AVG of column = 15% ← wrong
• Correct margin = (20+90)/(100+900) = 11% ← right

A measure calculates at the aggregated level automatically. A calculated column doesn't.

Fix: For any ratio or metric that aggregates across rows:

Profit Margin % = DIVIDE(SUM(Sales[Profit]), SUM(Sales[Revenue]), 0)

This calculates at whatever aggregation level the visual demands.

---

Mistake 3: Not Having a Proper Date Table

What it looks like: You use the built-in date hierarchy from your fact table's date column. Or you create a date table but don't mark it as a date table. Time intelligence functions appear to work — until they don't.

Why it's a problem: Power BI's time intelligence functions (TOTALYTD, SAMEPERIODLASTYEAR, DATEADD, etc.) require:

1. A standalone date table with one row per date
2. A contiguous range (no gaps, even on weekends)
3. Explicitly marked as a date table via Table tools → Mark as date table

Without this, time intelligence either throws errors, or — worse — silently returns incorrect values on certain date ranges, particularly around year/month boundaries.

Fix: Create a proper date table. The simplest DAX approach:

Date = CALENDAR(DATE(2020,1,1), DATE(2030,12,31))

Then add columns for Year, Month, Quarter, Week Number, Month Name, etc. Mark it. Connect it to every fact table's date column.

---

Mistake 4: Using Bidirectional Relationships as a Fix

What it looks like: A filter isn't flowing the way you need. You enable "Both" cross-filter direction on a relationship. The numbers change to what you expected. Problem solved — right?

Why it's a problem: Bidirectional relationships create ambiguous filter paths in the model. Power BI may evaluate filters via multiple paths, producing unexpected results in visuals that don't seem related to your change. More critically: in models with multiple many-to-many-style relationships, bidirectional filtering causes circular dependencies or non-deterministic results.

Bidirectional filtering is a band-aid over a modeling problem. It masks the issue rather than fixing it.

Fix: Investigate why the filter isn't flowing correctly. The solution is almost always structural:

• Wrong relationship direction (check your 1-side and many-side)
• Missing relationship through a shared dimension
• A fact-to-fact relationship that shouldn't exist
• A situation requiring CROSSFILTER() inside a specific measure rather than model-wide

Use bidirectional only when it's intentional and isolated — e.g., in role-playing dimension patterns with a bridge table and you understand exactly what you're doing.

---

Mistake 5: Writing Measures Without Variables (VAR)

What it looks like: A complex measure referencing the same sub-expression multiple times:

Growth % = 
DIVIDE(
    [Total Sales] - CALCULATE([Total Sales], SAMEPERIODLASTYEAR('Date'[Date])),
    CALCULATE([Total Sales], SAMEPERIODLASTYEAR('Date'[Date])),
    0
)

Why it's a problem:

1. CALCULATE([Total Sales], SAMEPERIODLASTYEAR(...)) is evaluated twice, doubling the computation
2. The measure is hard to read — you can't tell at a glance what the numerator and denominator are
3. If the logic needs to change, you must update it in multiple places, risking inconsistency

Fix:

Growth % = 
VAR CurrentSales = [Total Sales]
VAR PriorSales = CALCULATE([Total Sales], SAMEPERIODLASTYEAR('Date'[Date]))
RETURN
DIVIDE(CurrentSales - PriorSales, PriorSales, 0)

Variables are evaluated once and cached. The measure is readable. Each value is named. Modify once — applies everywhere.

---

Mistake 6: Not Removing Unused Columns from the Model

What it looks like: You connect a table with 40 columns to Power BI. You use 8 of them. The other 32 stay in the model because "they might be useful later."

Why it's a problem: Every column in the model takes memory and increases refresh time. Unused columns with high cardinality (like transaction IDs, timestamps, free-text fields) are particularly expensive — they compress poorly in VertiPaq and add significant model bloat without providing any analytical value.

A model with 32 unnecessary columns is not just wasteful — it actively slows every report that uses the dataset.

Fix: In Power Query, remove all columns that aren't needed for relationships, calculations, or display. Do this at the source — don't load and then hide. Hiding a column in Power BI still loads it into the model; removing it in Power Query does not.

---

Mistake 7: Mixing Grain Across Tables Without Accounting for It

What it looks like: Your fact table has daily sales at the product-store level. You bring in a budget table that has monthly targets at the store level (not product level). You relate them and start comparing actuals vs budget.

Why it's a problem: The grain mismatch means budget numbers are either being double-counted (because daily sales repeat the monthly budget for each day of the month) or producing blanks (because the product key doesn't exist in the budget table).

Fix: Always define the grain of every fact table explicitly. When grains differ:

• Create an appropriate bridge or summary table at the right level
• Use DAX to aggregate the finer-grain table to match the coarser grain before comparison
• Or use CALCULATE with ALLEXCEPT to scope the aggregation correctly

Grain mismatch is the most common cause of "wrong totals" that can't be explained by filters alone.

---

Mistake 8: Using BLANK() Results Without Handling Them

What it looks like: A measure returns BLANK for certain dimension members — products with no sales, months before the business launched. These blanks propagate into calculations: a growth measure divides by BLANK() and returns BLANK. A ranking measure skips those items. Visuals look cleaner than they should.

Why it's a problem: BLANK doesn't mean zero. In DAX, BLANK propagates through arithmetic — 5 + BLANK = BLANK, not 5. Measures that should show 0% growth show nothing. Trend lines skip months. Users trust visuals that are silently missing data.

Fix: Use COALESCE([Measure], 0) or IF(ISBLANK([Measure]), 0, [Measure]) only where zero is semantically correct (not where blank is the right indicator of no data). Use DIVIDE(numerator, denominator, 0) to handle division by zero. Audit your measures for blank propagation using a matrix visual with all dimension members showing.

---

Mistake 9: Publishing to the Wrong Workspace Without Testing

What it looks like: Development happens directly in a production workspace. Or a report is published from a developer's local Desktop file directly over a report other users depend on, overwriting a dataset with local-only changes.

Why it's a problem: In enterprise environments, publishing over the wrong report or dataset can:

• Break other reports that connect to the same dataset
• Overwrite tested configurations with untested local changes
• Cause data source errors if local credentials or connections differ from the service

Fix: Use deployment pipelines (Development → Test → Production). Never develop in production. Maintain a consistent connection strategy — parameterize source connections in Power Query so they can be overridden per environment. Build the habit of checking which workspace you're publishing to before every publish.

---

Mistake 10: Building the Report Before Designing the Model

What it looks like: An analyst starts with the data, drags fields into a canvas, Power BI auto-detects some relationships, and a report takes shape. The model is never explicitly designed — it emerges from the visuals.

Why it's a problem: Auto-detected relationships are often wrong — based on column name matching rather than actual data semantics. Fact tables end up with wrong cardinality. Dimensions aren't denormalized. Measures are written to work around model limitations rather than on top of a clean foundation.

The result is a report that works for its original purpose but breaks when extended, confuses future maintainers, and accumulates technical debt with every new requirement.

Fix: Design the model first. Define your fact tables and their grain. Define your dimension tables and their attributes. Build relationships explicitly and validate cardinality. Only then write DAX. Only then build visuals.

Model first → Measures second → Visuals last. This is the sequence that produces reports that last.

---

Technical Insight: The Diagnostic Toolkit

When something feels wrong in your model, use these tools to investigate:

• DAX Studio — free tool for running and timing DAX queries, identifying bottleneck measures
• VertiPaq Analyzer — inspects model size, column cardinality, and compression ratios
• Performance Analyzer (built into Power BI Desktop) — shows query duration per visual
• Model View — visually inspect relationships, cardinality, and cross-filter direction
• Matrix visual with all members — fastest way to validate whether a measure is producing correct results across all dimension combinations

---

Common Patterns Behind These Mistakes

Looking at these 10 mistakes together, three root causes emerge:

1. Layer confusion — using Power Query when you should use DAX, or calculated columns when you should use measures. Each layer has a purpose. Misusing them creates fragility.

2. Modeling skipped — treating Power BI as a visualization tool and underinvesting in the model. The model is the product. Visuals are the presentation layer.

3. No validation step — publishing reports without systematically testing measures across all filter combinations, especially edge cases (blanks, new categories, year boundaries).

---

Pro Tips

• Make a validation checklist before every publish: date table marked? all relationships correct cardinality? unused columns removed? key measures tested across all slicers?
• Peer review your models — fresh eyes catch grain mismatches and relationship errors faster than self-review
• Use meaningful measure names — Revenue_Actuals_MTD is clearer than Revenue when your model has 30 measures. Naming prevents wrong measures being used in wrong contexts.
• Comment complex measures — DAX supports // comments. Use them. Future you is a different person.

---

Summary

---

CTA

These mistakes are common because no one teaches the why behind Power BI best practices. Most tutorials teach you what to click — not why the model is designed a certain way, or what happens when you don't.

Namste Power BI — From Basics to Interviews teaches the reasoning behind every decision — data modeling, DAX logic, service architecture, and interview-level explanations of why each layer works the way it does.

Stop fixing mistakes in production. Build it correctly from the start.

devwithdata.in

---