6.3 · Best practices & pitfalls

Level 6 · In practice

6.3Best practices & pitfalls

Goal: adopt the right Power BI reflexes and avoid the most frequent design mistakes.
Estimated time: 10 min · If you only have 5 min: read “The essentials in 30s” + the diagram.

The essentials in 30 seconds

  • Structure: star schema (facts at the center, dimensions 1:*), cleaning at the source in Power Query, a dedicated and marked date table.
  • Measure & secure: explicit measures (DIVIDE, VAR/RETURN) stored in « _Measures », tested RLS, sensitive data outside the report.
  • Deliver: accent-color design, timed performance, publication in a team workspace and refresh that doesn't depend on your laptop.

Zineb's thread — the rule stuck on the wall

After a quarter, Zineb stuck her rule on the wall in Algiers: clean and proven first, fast afterwards. What mattered most wasn't one more brick, but three habits — star schema, explicit measures, tested RLS — and her biggest pitfall narrowly avoided: a report distributed to everyone while per-department security had not been verified.

Pick one single habit to anchor in your ritual, then move to the next.

The do's / don'ts of a reliable report

The difference between a makeshift build and a professional practice isn't in the visuals, but in the reflexes: a clean star schema, explicit measures, a color that means something, a secured, high-performing and truly refreshed report.

The model first

A well-built star schema makes DAX simple and performance correct. Conversely, staying in « single table » degrades everything: the star is not optional.

Meaningful rather than decorated

An accent color, neutrals, titles as statements: design serves the decision. Coloring every category in a rainbow makes the report pretty but mute.

✓ To do

  • Model as a star: facts at the center, dimensions around, 1:* relationships — the foundation of everything.
  • Clean at the source (Power Query) and create a dedicated date table, sorted and marked.
  • Prefer explicit measures (DIVIDE, VAR/RETURN), stored in « _Measures » and formatted.
  • Secure (tested RLS) and optimize on evidence (Performance Analyzer, in the order model → measures → visuals).

✗ To avoid

  • Staying in « single table »: DAX and performance degrade — the star is not optional.
  • Multiplying calculated columns when a measure would do; forgetting to format numbers.
  • Coloring every category (rainbow) instead of a meaningful accent; neutral titles.
  • Publishing an RLS without testing it, or distributing a sensitive report to too broad a workspace.
Common misinterpretation: « tick every box every day ». No. These are habits to install one by one: pick one (e.g. a star schema everywhere), anchor it in your ritual, then move to the next.
Text version of the diagram (SEO / screen readers / translation): 1) Model side — clean star, facts at the center, dimensions 1:*, dedicated and marked date table. 2) Calculation side — explicit measures (DIVIDE, VAR/RETURN), stored in « _Measures », formatted, without useless calculated columns. 3) Presentation side — meaningful accent design, titles as statements, tuned interactivity, no rainbow. 4) Production side — tested RLS, timed performance, publication in a team workspace and reliable refresh. Lesson: a healthy report is first modeled and proven — speed comes after.

Ready-to-say script — checking your report before sending (30s)

« Clean star? Marked date table? Measures in « _Measures »? Zero useless columns? Meaningful accent? Tested RLS? Timed performance? If any no, I fix it before sending. »

To reread just before distributing a report.

Ready-to-say script — explaining your design (30s)

« One accent color, neutrals, titles as statements, two to four slicers: my page serves the decision, it doesn't decorate. »

One sentence to recall that design serves the decision.

Copy-paste template — healthy measures

Total Revenue = SUMX(Sales, Sales[Quantity] * Sales[UnitPrice])
Average Basket = DIVIDE([Total Revenue], [Sales Count])
Growth % = VAR py = [Revenue PY] RETURN DIVIDE([Total Revenue] - py, py)
Share = DIVIDE([Total Revenue], CALCULATE([Total Revenue], ALL(Products)))

Copy-paste template — bad track to fix

-- BEFORE: frozen column, does not react to slicers
Column Revenue = Sales[Quantity] * Sales[UnitPrice]
-- AFTER: explicit reusable measure
Total Revenue = SUMX(Sales, Sales[Quantity] * Sales[UnitPrice])

SME / small budget

One habit per quarter is enough: star schema + clean measures first, the rest afterwards.

SME Algiers

Adapt the rituals to the closings: a slot for formatted measures + tested RLS held every month.

Remote / hybrid

Discipline #1 at a distance: named source, tested RLS and refresh date written down, even for small reports.

Intercultural

Check local usages rather than assuming: an unusual date or number format should raise a flag everywhere.

Caution: Generic reminder: golden rule — a healthy report is first modeled and proven; never distribute a scope without a tested RLS, keep sensitive data out of the report and check relationships, measures and totals before sending.

48h challenge — apply tomorrow

Run your report through the sieve: zero single table, zero useless column, zero untested RLS. Fix the first gap found.

Section exit checklist
  • I know the reflexes to adopt and the pitfalls to avoid.
  • I checked my critical points (star, measures, tested RLS).
  • I did the 48h challenge or scheduled its date.
Self-assessment 1-5: consistency of the right reflexes?pitfalls avoided?
Check your understanding

Before going to production, which reflex best protects Zineb?

💡

Golden rule: a star schema, explicit measures and a tested RLS — the rest (visuals, theme) only reveals this base.