
From Excel to Power BI: build your first real dashboard (you already know more than you think)
Article Summary
You're not starting from zero. A pivot table is a matrix visual, VLOOKUP is a relationship, and your first dashboard is five steps away.
A finance manager I tutor — call her R — booked a session in a mild panic. Her director had said the magic words: "Can you put this in Power BI?" She'd been running the same monthly numbers in Excel for six years. Pivot tables in her sleep, VLOOKUPs across four tabs, conditional formatting that would make you weep. And now she was convinced she had to learn a whole new profession by Friday.
Twenty minutes in, she said the thing almost everyone says: "Wait — that's just a pivot table." Yes. That's the whole secret. Power BI isn't a new skill so much as a new home for skills you already have. The vocabulary changed; the thinking didn't.
So let's do what I did with R. We'll map what you know in Excel onto what it's called in Power BI, then build an actual dashboard in five steps. By the end you'll have something you can publish and send to your director. You will not be a Power BI expert. That's fine — neither was R, and her dashboard still went into the Monday meeting.
You already speak most of this language
Power BI Desktop is three tools wearing a trenchcoat: Power Query (the data-cleaning step), the data model (where tables connect), and the report canvas (where you drag out charts). If you've ever used Get & Transform or Power Pivot inside Excel, you've already touched all three — they're the same engines.
Here's the translation table I sketch on the whiteboard:
| In Excel you say… | In Power BI it's called… | What's actually different |
|---|---|---|
| Pivot table | Matrix visual | Lives on a canvas; cross-filters other visuals |
| VLOOKUP / XLOOKUP across tabs | Relationship between tables | You connect tables once, not per-formula |
| Named range / a clean table | part of the semantic model | The model is the reusable "source of truth" |
| Pivot calculated field | Measure (written in DAX) | Recalculates for whatever you've filtered |
| A helper column with a formula | Calculated column | Stored on disk; use sparingly |
| Slicer | Slicer (same word, same idea) | Filters the whole page, not one pivot |
| The Data tab / Get & Transform | Power Query | Identical engine, roomier window |
One real naming note so you don't get confused reading docs: Microsoft renamed what used to be called a "dataset" to a semantic model back in November 2023, because "dataset" meant ten different things across Fabric. Older blog posts and YouTube videos still say "dataset." Same object. If a tutorial from 2022 says dataset and your screen says semantic model, you're not lost — the world just relabelled the tin.
The "semantic model" name is also doing honest work. It's the layer that holds your tables, the relationships between them, and your measures — the meaning of your data, not just the rows. Once it's good, every report you build on top inherits it. That's the bit Excel never quite gave you: a clean model you build once and reuse.
VLOOKUP is a relationship now (and it's better)
This is the conceptual jump worth slowing down for. In Excel, every time you wanted the customer's region next to their order, you wrote another VLOOKUP. Twelve tabs, twelve lookups, and one renamed column away from #N/A everywhere.
In Power BI you do it once. You load an Orders table and a Customers table, then drag CustomerID from one onto CustomerID in the other. That's a relationship. Now anything in Customers is "reachable" from Orders automatically — no formula copied down 40,000 rows.
If you genuinely need a lookup written out as a formula, Power BI has RELATED (which rides an existing relationship, like a virtual VLOOKUP) and LOOKUPVALUE (which doesn't need one). But the official guidance — and mine — is to build the relationship and reach for those functions rarely. The relationship is the feature; the DAX lookup is the escape hatch.
The payoff is real. In Excel a lookup is glue you reapply forever. In Power BI you wire the tables together once and stop thinking about it. R had been maintaining the same four VLOOKUPs since 2019. We replaced them with two relationships in about a minute, and her jaw was genuinely on the floor.
The one measure worth learning first
People think DAX is the scary part. It can be, eventually. But you can ship your first dashboard knowing essentially one pattern.
Start with a basic aggregation as a measure, not a calculated column:
Total Sales = SUM(Orders[Amount])Now the important word: context. A measure recalculates for wherever it lands. Drop Total Sales into a card and it's the grand total. Drop it in a matrix by month and it's per-month. Click a slicer for "North region" and every instance updates. You wrote the formula once; the visual decides what it means. That single idea — a measure respects the filters around it — is most of what makes Power BI feel alive compared to a static pivot.
The second thing to learn, when you're ready, is CALCULATE — the function that lets you change the filters a measure sees:
Sales North = CALCULATE( SUM(Orders[Amount]), Orders[Region] = "North" )That reads as: "sum the amount, but force the region to North regardless of what's clicked." Microsoft's own DAX reference describes CALCULATE as the function that evaluates an expression in a modified filter context, and in practice it shows up in a huge share of real business measures — almost anything more interesting than a plain total goes through it. You do not need it for your first dashboard. Just know its name, because the moment you want "% of total" or "same month last year," that's the door.
Why measures beat calculated columns (mostly)
New folks reflexively make calculated columns because they feel like Excel helper columns. Resist it. The practical differences, straight from Microsoft's guidance:
- A calculated column is computed once when the data refreshes and stored — it eats disk and RAM, and it can't react to a slicer.
- A measure is computed on the fly in the current filter context. It uses CPU at view time, not storage, which scales far better on big tables.
The rule of thumb I give every student: if you want to sum, average, or count something — make a measure. Only reach for a calculated column when you need the value to physically exist in a row, for example so you can slice or filter by it (you can't put a measure on a slicer). Get this one habit right and you've dodged the single most common beginner mistake.
Five steps to an actual dashboard
Here's the path R and I walked. CSV or Excel file, to something published, in one sitting.
1. Connect your data
Get data → Excel workbook or Text/CSV → pick your file → Transform Data (don't just hit Load). That opens Power Query. Spending thirty seconds here saves you an afternoon later.
2. Fix the data types — this is where everyone gets bitten
In Power Query, look at the little icon on each column header. 123 is a whole number, the ABC icon is text, the calendar is a date. The number-one beginner trap is numeric columns imported as text. A leading space, a stray currency symbol, or a CSV quirk and your "Amount" comes in as text — then SUM quietly returns blank or throws an error and you assume Power BI is broken. It isn't; the column is text.
Click the column, set the type explicitly (right-click → Change Type, or the header icon). Set dates to Date, amounts to Decimal Number, IDs to Whole Number or Text. Then Close & Apply. If a measure ever returns nothing or errors, check your column types first — it's the cause nine times out of ten.
3. Build three visuals that cross-filter each other
On the report canvas, drag out three things:
- A card for
Total Sales(your headline number) - A column chart of
Total Salesby month - A matrix of sales by product or region — your familiar pivot table
Now the trick that makes it feel like a dashboard: click a bar in the column chart. The card and the matrix both update to that month. That cross-filtering is automatic — visuals on the same page talk to each other for free. This is the moment it stops looking like Excel and starts looking like Power BI, and it's the moment my students usually grin.
4. Add a slicer — and avoid the trap that ruins it
Drag a field like Region onto a blank spot and, in the Visualizations pane, choose the Slicer. Now you've got clickable buttons that filter the whole page.
The classic gotcha: a student adds a slicer, it filters one chart but not the others, and they conclude Power BI is haunted. What actually happened is interactions got edited — either manually, or a visual was pasted from elsewhere. Select the slicer, go to the Format ribbon → Edit interactions, and confirm every other visual is set to Filter (the funnel), not None. By default a slicer filters everything on its page; if one chart ignores it, that switch is why.
5. Publish
File → Publish → choose a workspace, and your dashboard lands in the Power BI service in the browser, shareable by link (sharing beyond yourself depends on your org's licensing — that's a chat for your IT team, not a blocker on building). Refresh schedules and apps come later. For now: you built a thing, and it's live.
An honest scope check
Let me be straight, because hype helps no one. Five steps gets you a real, useful, shareable dashboard. It does not get you Power BI mastery. We didn't touch star schemas, incremental refresh, row-level security, time-intelligence DAX, or Power BI's role inside Microsoft Fabric. Those matter when you go from "this is handy" to "the finance team runs on this." They're a few months of deliberate practice, not a Friday afternoon.
But that gap is smaller than it looks from where R was sitting. The hard part of analytics was never the tool — it was knowing which numbers matter and how they relate. You learned that in Excel over six years. Power BI just gives that knowledge a better stage. You really do already know more than you think.
Recap
- A pivot table is a matrix visual, a VLOOKUP is a relationship, a slicer is a slicer — you've met most of this before.
- "Dataset" was renamed to semantic model in late 2023; same object, the model is your reusable source of truth.
- Build measures for sums/averages/counts; save calculated columns for when a value must exist in a row (like for slicing).
- Learn one measure first (
SUM), understand that it respects context, and meetCALCULATEwhen you're ready for ratios and time comparisons. - Two traps cause most beginner pain: numbers imported as text (fix types in Power Query) and a slicer filtering one chart (check Edit interactions).
If you'd like a hand making that Excel-to-Power-BI jump without the Friday panic, this is exactly the kind of thing I walk through one-on-one — we'd take your spreadsheet and turn it into a working dashboard together, not a toy dataset. You can see how I teach it on my Power BI tutoring page, and the first session is free, so there's no risk in finding out whether it clicks for you the way it did for R.
Enjoyed this post? Get the next one in your inbox.
A short, useful email when there's a new tutorial, study guide, or career-prep post on the blog. No spam, unsubscribe anytime.
Written by Ali Jabbary
M.Sc., P.Eng. • Expert Data Scientist & ML Engineer with 10+ years of experience. 500+ students helped worldwide. Specializing in Python, AI/ML, and turning complex problems into simple solutions.


