Want a structured way into Power BI? Our hands-on Analyze & Visualize with Power BI classroom training in Singapore walks you through the full workflow — model, DAX, visuals, publish — and is WSQ-funded for eligible Singaporeans.
TL;DR — Power BI best practices come down to four pillars: a clean star-schema data model, well-named DAX measures (not calculated columns), question-led visual choices, and aggressive performance tuning through query folding and incremental refresh. If you only do one thing, build a proper star schema. Everything else — governance, sharing, RLS — sits on top of that foundation.
After 24 years of training in Singapore, I have watched hundreds of working analysts open Power BI for the first time. The pattern is always the same. They jump to the visualisation pane, pick the prettiest chart, and start dragging fields into it. Six months later they wonder why their report takes four minutes to refresh and the numbers do not match the source. The fix is almost never in the chart. It is in the model underneath.
Power BI best practices are easy to list and hard to rank. Search for them and you will see 30 or 35 numbered items, all treated as equal weight. That is the wrong way to learn them. A small number of decisions account for most of the pain or relief you will feel six months in. This guide ranks them by impact, drawn from the classroom — not from a feature comparison sheet.
A best practice is not a rule. It is a default that produces good outcomes for most reports, most of the time. If you understand why the default exists, you can break it on purpose. If you do not, you will break it by accident — and you will blame Power BI when it is really you.
Power BI best practices sit across five areas:
About 80 per cent of the headaches you will see in a real Power BI deployment come from the first item: data modelling. Most teams skip straight to visuals because that is the fun part. Then they wonder why the report is slow and the numbers do not add up. If you are still finding your way around the product, the companion Power BI how-to guide for beginners covers the basics before you read the rest of this article.
The rest of this guide goes pillar by pillar. The practices are ranked by what actually moves the needle for your boss, not by what scores well on a quiz.
If you read only one section, read this one.
A star schema has one or more fact tables (transactions, sales, events) connected to dimension tables (date, product, customer, region). The fact table sits in the middle. The dimension tables radiate out from it. That is the star.
Think of it like a meeting room. The fact table is the conference table in the middle, holding all the action. The dimension tables are the chairs around it, each holding one type of detail — who, what, when, where. The conversation flows from the chairs to the table and back. Clean. Predictable.
The alternative is a snowflake schema, where dimensions are split into further sub-tables (product → product category → product family). Snowflakes feel tidy to anyone who learned database normalisation in school. In Power BI, they are slower, harder to filter, and produce more confusing DAX.
Default to star. Flatten your dimensions during data load. Power BI’s compression engine handles wide tables better than people expect. For more on building visualisations on top of a clean model, see our guide to data visualization with Power BI.
Set every relationship as one-to-many (1:*) wherever possible. Set the cross-filter direction to single — from the dimension side to the fact side. Bi-directional and many-to-many relationships are valid tools, but they slow queries and create ambiguous filter paths. Use them only when you can explain the specific reason out loud.
This is where most beginners go wrong. A calculated column computes once per row at refresh time and is stored in memory. A measure computes at query time, only for the rows currently filtered in the visual.
For any aggregation — sum, count, average, percentage, ratio — always use a measure. Calculated columns belong only when you need a value to slice or filter by, and the value cannot come from the source. Examples: a fiscal-year flag, a customer-segment bucket. Even then, push the calculation back to the source database if you can.
The calculated-column trap is when an analyst writes Total Sales = SUM(Sales[Amount]) as a calculated column. It works. It also bloats the model, breaks filtering, and tells your colleagues you have not read the documentation. Use a measure.
Power BI auto-generates a hidden date table for every date column in your model. This is convenient and wasteful. Replace it with one custom date table connected to every fact-table date column. You will get cleaner time-intelligence DAX, a smaller model, and predictable behaviour across reports.
Floats produce rounding errors in financial reports. Use Decimal (fixed) or Whole Number wherever you can. The day a finance manager finds a $0.01 mismatch in your dashboard is the day you stop using floats. Managers can be quite demanding about that one cent.
DAX is a measure-writing language. Not a programming language. Most of the common mistakes come from treating it like Python or Excel.
Repeating this because it matters. Every aggregation should be a measure.
Variables make measures readable and faster:
Profit Margin =
VAR Revenue = SUM(Sales[Amount])
VAR Cost = SUM(Sales[Cost])
RETURN DIVIDE(Revenue - Cost, Revenue)The variable is calculated once per filter context, not every time it is referenced. Use them. Your future self, debugging this at 11pm, will thank you.
/ operatorRevenue / Cost will error on a divide-by-zero. DIVIDE(Revenue, Cost) returns a clean blank, or a value you specify. Always use DIVIDE.
Total Sales — good. Calc1, Measure 4, Sum of Amount 2 — bad. The model browser is a public space. Other people will see your names. Give measures business-friendly names. Group them in display folders if your model has more than 15 measures.
IFERROR swallows real bugs. Use proper conditional logic (IF, SWITCH) and validate at the data-load stage instead. An error you can see is an error you can fix.
For query-style aggregations, SUMMARIZECOLUMNS is the modern, faster choice. SUMMARIZE still works, but the Power BI engine optimises SUMMARIZECOLUMNS better.
Power BI’s Quick Measures feature builds common patterns — year-over-year, percentage of total, running total — without you writing the DAX yourself. Use Quick Measures, then read the generated code. It is the fastest way to learn the patterns. Our Power BI quick measures explainer walks through this in depth.
A pattern I see repeatedly in our classrooms: Singapore analysts are over-trained on DAX theory and under-trained on application. Most have heard of CALCULATE. Few have used it under pressure with a manager standing behind them. The way to fix that is reps, not reading. For deeper architectural reading, Microsoft’s official Power BI guidance documentation covers the supporting patterns once you have the fundamentals down.
A common scene in our classroom: the analyst opens Power BI, scrolls the Visualizations pane, picks the chart that looks the most interesting, then tries to fit data into it. That is backwards.
Pick the chart from the question, not from the visualisation pane.
If the question is “which region sold the most?”, you want a bar chart. If the question is “how did sales trend across the year?”, you want a line chart. Same data, different chart. The question decides.
Limit each report page to roughly five primary visuals. Eight maximum. Microsoft’s own optimisation guide and most performance-tuning posts agree on a similar cap. More than eight visuals on a page produces visual noise, slows the render, and tells the reader you could not decide what was important. A senior manager only has 30 seconds for your dashboard. Don’t waste it.
The Q&A visual lets users type natural-language questions like “show sales by region last quarter” and get a chart back. It is genuinely impressive in demos. In production, it is a maintenance burden. It needs synonyms. It hides errors silently. It is unreliable for mission-critical reports. Put it on exploration pages. Keep it off executive dashboards.
Use tooltips to add detail without crowding the page. Use drill-through pages instead of stacking visuals. Use bookmarks for guided narratives. These three features separate a report that looks built by an amateur from one that looks built by someone who has shipped a few.
Power BI reports get shared in meetings, projected on screens, exported to PowerPoint, printed on A4 paper. Use a light background. Pick a colour palette that survives black-and-white printing. Avoid red-green as your only signal — roughly 8 per cent of men have some form of colour-vision deficiency. Your dashboard goes to many readers, and at least one of them will not see red the way you do.
Stick to 16:9, 1280 × 720 or higher. Custom canvas sizes look clever in Power BI Desktop and break the moment someone opens the report on a different screen, embeds it in SharePoint, or exports to PowerPoint.
Performance is where you feel the cost of bad modelling. A well-modelled report performs almost regardless of size. A badly-modelled report crawls at 50,000 rows. Your boss will not care about the difference between Import and DirectQuery. They will care that the dashboard takes four minutes to load.
A table visual showing 100 million rows is loading 100 million rows. Set a Top-N filter — 10,000 or whatever the user actually needs — on every visual that could explode. The user experience does not change. Memory usage drops by orders of magnitude.
Query folding is when Power Query pushes your transformations back to the source database as SQL. The source does the work. Power BI receives a smaller result. To check folding, right-click a step in Power Query and look for “View Native Query”. If it is greyed out, the fold broke at that step.
The most common fold-breakers: adding a custom column with Power Query M, sorting before filtering, and merging queries from different sources. Re-order your steps so folding survives as long as possible.
If your fact table has 5 million rows or more, set up incremental refresh. Power BI will only re-load the new or changed rows on each refresh, instead of the whole table. Refresh time typically drops from hours to minutes. How good is that?
If your tenant is in Singapore (Southeast Asia) and your SQL Server is in West Europe, every refresh and DirectQuery sends data across the planet. Move the gateway and the source into the same region as the tenant. The latency saving alone is worth the migration.
A single gateway serving both gets overloaded during refresh windows. Live connections become slow exactly when the boss is in front of the dashboard. Split them.
Every visual fires at least one query. Eight visuals on a page means at least eight queries on every interaction. Limit to five primary visuals. Push detail into drill-through pages and tooltip pages.
Best practices stop being technical and start being organisational the moment more than one person uses a report.
My Workspace is for prototyping. Anything anyone else needs to see goes into a proper workspace, with a name like Sales-Production, Finance-Reporting, or HR-Analytics. Workspaces have access controls, audit logs, and version history. Personal workspaces have none of these.
For any report that goes into a business decision, create three workspaces: development, test (UAT), and production. Promote reports through them with deployment pipelines if you are on Premium or Premium Per User. This is the same release discipline software teams have used for thirty years. Reports are software. Treat them that way.
RLS restricts which rows a viewer can see. Common use cases: a salesperson sees only their accounts; a regional manager sees only their region. Keep RLS rules simple. One role per business function. Push complex calculations back to the source database where possible. Test every role with the “View as Roles” tool before publishing.
If your organisation uses Microsoft 365, apply sensitivity labels (Public, General, Confidential, Highly Confidential) to datasets and reports. The labels follow the data — into Excel exports, PowerPoint embeds, email attachments. For Singapore organisations handling PDPA-relevant data, sensitivity labels are the cleanest way to keep classification consistent across the Microsoft stack.
Power BI has built-in usage metrics for every workspace and report. Check them. A report nobody opens is a report you can deprecate. A report 200 people open every Monday morning needs a performance review and a dedicated owner.
If you are preparing for a Power BI interview, the questions below come up almost every time. The answer matters less than what the interviewer is testing for.
1. What is the difference between a calculated column and a measure?
What they are testing: whether you understand storage versus query-time computation. Mention that columns are computed at refresh and stored in memory; measures are computed at query time per filter context. Say “I default to measures.”
2. What is a star schema and why do you prefer it?
What they are testing: whether you have actually built a model, or just used one someone else built. Mention fact tables, dimension tables, single-direction one-to-many relationships. Compare to snowflake briefly.
3. What is DAX and how is it different from Excel?
What they are testing: whether you understand filter context. Say DAX is column-and-table aware, has row context and filter context, and the same expression behaves differently inside a measure versus a calculated column.
4. What is Row-Level Security and when have you used it?
What they are testing: whether you have worked on shared reports in a real org. Have one specific example ready.
5. What is the difference between Import, DirectQuery, and Composite modes?
What they are testing: judgement. They want to hear you default to Import unless there is a reason.
6. How do you optimise a slow Power BI report?
What they are testing: methodology. Walk through Performance Analyzer → identify slow visual → check DAX query → check model → check storage mode. Order matters. Random fixes do not impress.
7. What is incremental refresh?
What they are testing: exposure to large datasets. If you have not used it, say so honestly — and mention you understand the pattern.
8. Have you used Power BI Service for sharing? What is a workspace?
What they are testing: whether you have shipped beyond Power BI Desktop. Mention workspaces, apps, deployment pipelines if you have used them.
If you can answer all eight clearly with specific examples from your own work, you will pass most Power BI screens. The interviewer is not looking for textbook answers. They are looking for someone who has shipped real reports and learned from the messy bits.
The Power BI shelf is crowded. These are the resources working analysts actually finish.
learn.microsoft.com/training/powerplatform/power-bi covers the basics with hands-on labs and earns you a Microsoft badge at the end. Better than most paid courses for absolute beginners.sqlbi.com/articles is a goldmine. Most DAX patterns you will need are written up there.For PDFs specifically, Microsoft publishes free e-books and whitepapers under their Power BI documentation hub. Search “Power BI whitepaper” on learn.microsoft.com and you will find ten or twelve worth downloading.
For a structured classroom path in Singapore, our Analyze & Visualize with Power BI course covers the full pipeline — connecting to data, building the model, writing DAX, designing visuals, publishing to the service. The course is WSQ-funded under SkillsFuture for eligible Singaporeans, which brings the cost down significantly. The companion Data Analytics with Excel & Power BI course is useful if your team still spends most of the day in Excel and wants the Power BI bridge. Analysts who want to deepen Excel modelling before tackling Power BI’s data model often start with Advanced Data Analytics & Visualization with Excel.
Both run as public classes and as in-house corporate sessions. We have run Power BI training for 12,600+ companies across SME, banking, finance, and manufacturing, and the same pattern shows up everywhere: the people who finish the class and apply it the next Monday morning get fluent in about three weeks. The people who go back to the office and never open Power BI again forget it in three weeks. Training without practice is theatre.
Once you have read the books and taken the course, find a free Power BI quiz online and time yourself. Microsoft’s own DA-100 / PL-300 practice tests are the closest to the real interview level. If you can score 80 per cent on those without notes, you are interview-ready.
Build a clean star schema. A correct data model — fact tables in the middle, dimension tables around them, single-direction one-to-many relationships — solves most of the performance, DAX complexity, and reporting flexibility problems before they appear. Every other best practice (DAX, visuals, performance tuning) becomes easier on top of a good model. If you only have time to learn one thing, learn star schema.
A star schema is a data-model pattern with one or more fact tables (containing transactions or events) connected to dimension tables (containing descriptive attributes like date, product, customer). Power BI’s storage and query engine is optimised for this pattern. Star schemas produce faster queries, simpler DAX, and cleaner filter behaviour than the alternative (snowflake). It matters because almost every problem you will hit later — slow reports, weird filter behaviour, complex DAX — traces back to a non-star model.
Default to measures. A calculated column is computed at refresh time and stored in memory, taking up space and slowing refresh. A measure is computed at query time, only for the data currently shown. For any aggregation (sum, count, average, percentage), use a measure. Use a calculated column only when you need a value to slice or filter by, and the value cannot come from the source.
Open Performance Analyzer (View → Performance Analyzer in Desktop) and find the slow visuals. From there, work backwards: is the DAX measure too complex? Is the model star-shaped? Is the storage mode right? Is there a Top-N filter limiting row counts? Common quick wins: reduce visuals per page to five, replace bi-directional relationships, switch from calculated columns to measures, set up incremental refresh on large fact tables, and check that query folding still works in Power Query.
The most common ones cover star schema versus snowflake, calculated columns versus measures, Import versus DirectQuery, Row-Level Security, DAX filter context, incremental refresh, Power BI Service workspaces, and how to optimise a slow report. Interviewers are testing whether you have shipped real reports, not whether you have memorised definitions. Have a specific example ready for each.
Yes. Microsoft Learn has the complete Power BI learning path for free, with hands-on labs. SQLBI publishes free articles and whitepapers covering most DAX patterns. Microsoft itself publishes free e-books under the Power BI documentation hub. Paid books worth buying afterwards: “The Definitive Guide to DAX” by Russo and Ferrari is the reference.
Import is better for most reports. Data is loaded into Power BI’s in-memory engine, queries are fast, and DAX behaves predictably. DirectQuery is the right choice only when the dataset is too large to import, when data must be near-real-time, or when corporate policy forbids data movement. DirectQuery is slower per query and has DAX limitations. Default to Import unless you have a specific reason not to.
You define roles in Power BI Desktop (Modeling → Manage Roles) and write DAX filter expressions for each role — for example, [Region] = "APAC". Then in Power BI Service, you assign users or AAD groups to each role. When a user opens the report, Power BI applies the filter automatically, and that user can only see rows that pass the filter. Test every role with “View as Roles” before publishing. Keep the filter logic simple — push complex logic back to the source database.
I hope this guide has been useful. Power BI rewards the people who get the model right and keep going. If you want a structured way to get there, do try our Analyze & Visualize with Power BI course — two days, hands-on, WSQ-funded, with a trainer who has been in the classroom for 24 years. Open a sample dataset this week, build a star schema from it, and write your first three measures. That is the fastest way to make any of this stick.
How to Use Presenter View in PowerPoint (Zoom, Teams & Dual Monitors) To use PowerPoint…
Want to use Canva properly for resumes, decks and team comms? Our Canva Design Masterclass…
How to Use Power Automate to Send Emails (Full Guide) To send emails with Power…
Power BI Quick Measures Explained (10 You'll Actually Use) A Power BI Quick Measure is…
How to Add Animations in PowerPoint (Step-by-Step + Examples) TL;DR: To put animation in PowerPoint,…
Want to sharpen your professional email writing end-to-end? Our hands-on Writing Professional Emails course covers…