Power BI for business analysts

What Power BI is, in plain English

Power BI is a business intelligence (BI) product from Microsoft. "Business intelligence" simply means tools that turn raw data into something people can read and act on: charts, tables, filters and summary numbers. The official product documentation lives at learn.microsoft.com/en-us/power-bi.

Three words come up constantly, and beginners often mix them up:

• A report is a set of pages with visuals (charts, tables, cards) that users can filter and click.
• A dashboard, in everyday language, is a one-screen summary of the most important numbers. (Power BI also uses "dashboard" for a specific item that pins tiles from several reports; in meetings people often use the words loosely, so always ask what is meant.)
• A data model (sometimes called a semantic model or dataset) holds the tables, the relationships between them and the calculations that reports use.

Data usually flows in one direction: source systems (databases, spreadsheets, apps), then a data preparation step, then the model, then the report. Each stage is a place where a requirement can go wrong, which is why a business analyst cares about all of them.

Why a business analyst needs Power BI knowledge

Almost every project ends with someone asking "how will we know it worked?" The answer is a report. A business analyst is often the person who turns a stakeholder's vague wish ("I want visibility on late payments") into a precise specification that a report builder can implement and a tester can verify. Knowing the tool's vocabulary lets you:

• Ask better questions in elicitation sessions: who looks at this, how often, on what device, and what do they do next?
• Define measures unambiguously so two reports never give two answers.
• Judge what is easy (a filter) and what is hard (a metric that needs data no system stores).
• Write acceptance criteria for reports, not only for screens.

Some job adverts for business analysts mention Power BI; many do not. Even when it is not required, the thinking applies to Tableau, Looker, Excel or any other reporting tool. For how this differs from a dedicated data role, see business analyst vs data analyst.

The five concepts to learn first

1. Tables and relationships

A good model separates fact tables (events you count or add up, like sales lines) from dimension tables (descriptions you slice by, like products, customers and dates). Facts connect to dimensions through keys. This arrangement, often drawn as a "star" with the fact table in the middle, is easy for people and the tool to understand. It is the same idea as primary and foreign keys in SQL.

2. Data preparation

Source data is rarely clean: dates stored as text, "UK" and "United Kingdom" in the same column, blanks. Power BI includes a preparation tool called Power Query for cleaning and reshaping data before it reaches the model. As a BA, you write the rules ("treat blank country as Unknown"); someone else may implement them.

3. Measures

A measure is a calculation that responds to filters, such as total sales, number of orders or average order value. Power BI's formula language is called DAX. A DAX measure looks like a spreadsheet formula:

Total Sales = SUM(Sales[Amount])
Order Count = DISTINCTCOUNT(Sales[OrderID])
Avg Order Value = DIVIDE([Total Sales], [Order Count])

You do not need to write DAX on day one, but you must be able to say exactly what each measure includes. Does "Total Sales" include tax, refunds, cancelled orders? Write it down.

4. Visuals

Choose the chart that matches the question. Compare categories with bars, show change over time with lines, show part-to-whole with a few stacked bars or a table, show a single key number with a card. Avoid decoration. The glossary entry on data visualisation covers the basics.

5. Filters and security

Slicers (clickable filters) let viewers narrow data by date, region or product. Row-level security limits which rows a person may see, for example a regional manager seeing only their region. Security is a requirement, not an afterthought: ask early who may see what.

Worked example: a dashboard request at CartNest

CartNest is a fictional online shop. Priya, the head of e-commerce, says: "I want a sales dashboard." That is not yet a requirement. Here is how a BA moves from the wish to a specification.

1. Find the decision. Priya's weekly meeting decides which categories get promotion budget next week. So the dashboard must show category performance this week against last week.
2. Define the measures.

3. List the cuts. Date (day, week), category, country, device.
4. Sketch the page. Top row: four cards (Net sales, Orders, AOV, Return rate) each with change versus last week. Middle: bar chart of net sales by category. Bottom: line chart of net sales by day. Slicers for date and country.
5. Write the rules. Refresh daily at 06:00 local time; figures are up to the previous midnight; a visible "data as of" label; the regional manager sees only their country.
6. Write acceptance criteria. "Given the sample week in the test data, when the report is filtered to Books, then Net sales equals the value in the reconciled finance extract." Use real numbers from a reconciliation so the tester can prove it.

Notice what the BA produced: a decision, definitions, a layout and testable rules. No software was needed for any of it. See KPI vs metric for how to choose the right measures.

Step by step: from request to report

1. Ask who and why. Who will use it, in what meeting or process, and what will they do differently after seeing it?
2. Check the data exists. Find the source tables and fields. Run a few SQL checks for gaps or duplicates.
3. Define every measure and filter in a table like the one above, including what is excluded.
4. Sketch wireframes on paper or a whiteboard before anyone builds.
5. Agree the refresh and access rules with the data owner and security team.
6. Review early with the stakeholder using a rough prototype, not a finished report.
7. Reconcile and test. Compare report numbers with a trusted source for a fixed period, then run user acceptance testing with real users.
8. Document definitions where users can find them, for instance on a documentation page.

Where dashboard numbers go wrong

A dashboard is only as good as the trust people place in it, and trust is lost quickly. When a number is challenged, the cause is almost always one of the following. Walk through this list with the team before launch.

• Different definitions. Sales counts orders when placed; finance counts them when paid. Both are right, but they produce different totals. Pick one, name it clearly ("Net sales, paid basis") and show the definition on the page.
• Timing. Data is refreshed at 06:00, but the meeting is at 05:00, so the numbers are a day old. Time zones add a second layer: is "today" measured in the head office time zone or the customer's?
• Duplicates and missing rows. A join that repeats rows inflates totals; a missing relationship leaves some sales without a category. SQL checks such as those in SQL joins explained find these problems before users do.
• Blank and unknown values. If 8 percent of orders have no country, a "sales by country" chart quietly hides them. Show an explicit "Unknown" bar and track it over time.
• Filters that surprise. A page filtered to one region may sit next to a card that ignores the filter. Decide which numbers respond to which slicers and label the exceptions.
• Changing history. If a product moves from one category to another, do past sales move too? Agree the rule, because it changes last year's chart.

Make a short "known limitations" box part of the specification. Stakeholders forgive limitations they were told about; they do not forgive surprises. Finally, ask who owns the report after launch. A dashboard without an owner slowly drifts away from reality as the business changes, and nobody notices until a number is wrong in a board meeting.

Common mistakes

• ✅ Start from the decision the report supports. ⚠️ Starting from "what charts can we make".
• ✅ Define each measure in one place with inclusions and exclusions. ⚠️ Letting "revenue" mean three things on three pages.
• ✅ Show the date the data was last refreshed. ⚠️ Users trusting stale numbers without knowing it.
• ✅ Limit a page to a handful of visuals. ⚠️ Cramming twenty charts on one screen so nothing stands out.
• ✅ Reconcile to a trusted source before launch. ⚠️ Discovering in front of executives that the report disagrees with finance.
• ✅ Plan access rules early. ⚠️ Adding security after a sensitive number has already been shared widely.
• ✅ Use colour to carry meaning (for example, red only for bad). ⚠️ Rainbow colours that mean nothing and fail for colour-blind viewers.

Reader exercise

Pick any shop or service you know. Write a one-page dashboard spec: (1) the decision it supports, (2) four measures with definitions including exclusions, (3) three filters, (4) a sketch of the layout in words, (5) two acceptance criteria that use real example numbers. Then show it to a friend and ask them what they would do after reading it. If they cannot answer, the dashboard has no purpose yet.

How to practise in the BA Lab

Stage 10 of the BA Lab, Dashboards and Power BI concepts, lets you practise requesting, defining and sketching dashboards for a fictional company, with checks that flag missing definitions and vague measures. To be clear about what this is: it is browser-based concept practice for the thinking and specification skills, not Microsoft Power BI itself. To learn the real product, use Microsoft's own free tools and documentation alongside it. The pricing page shows which packages include the dashboard stage, and the demo gives a free look at the Lab's style.

Courses and practice help you build skills and a portfolio; they do not guarantee a job or any Microsoft credential.

Frequently asked questions