1. Choosing the Right Visual
The most common dashboard mistake isn't a wrong number — it's the right number shown in a visual that hides it. Match the visual to the actual question:
- Trend over time → line chart.
Sales YTDby month reads instantly as a line, far less clearly as a table. - Comparing categories → bar or column chart, sorted by value rather than left alphabetically.
- Part-to-whole → a stacked bar, or (only with 2–4 slices) a donut — beyond that, a pie or donut becomes unreadable.
- A single headline number → a card visual, often paired with a small trend sparkline.
- Exact numbers someone needs to read precisely → a table or matrix — charts are for pattern recognition, not for reading exact figures off.
Gauges compress a lot of visual space into one number that a card would show more clearly, and a pie chart past a handful of slices forces a viewer to compare angles rather than lengths — something the human eye is genuinely bad at. Reach for a bar chart before either.
2. Report Design Principles
Beyond individual visuals, a few layout habits separate a dashboard someone trusts from one they squint at:
- One dominant question per page. A page trying to answer everything ends up answering nothing clearly — split a busy report into multiple focused pages instead.
- Top-left gets read first. Put the single most important KPI card (Total Sales, for instance) top-left, with filters and slicers along the top or a left rail.
- Consistent color per category, across every visual on the page. If Electronics is blue in one chart, it should be blue everywhere else on that page too.
- Title every page and every visual. "What am I looking at?" should never require a guess.
3. Slicers & Cross-Filtering
A Slicer visual, bound to a field like Category or a
date range, lets a viewer filter the whole page interactively without touching the
underlying data or measures. By default, clicking a data point in one visual also
filters or highlights every other visual on the page — that behavior is editable per
visual pair via Format → Edit Interactions, which offers three modes
per target visual: Filter, Highlight, or
None.
Turning a visual's interaction to None is the right call whenever clicking one chart shouldn't be allowed to change another — a KPI card meant to always show the grand total, for example, regardless of what's clicked elsewhere on the page.
4. Drill-Through Pages
A drill-through page is a dedicated detail page that automatically
filters to whatever a viewer right-clicked on a summary page — set up by dragging a
field (e.g. Category) into the Drill through well in
the Visualizations pane on the detail page. From then on, right-clicking a category
on the summary page's chart shows a Drill through option that jumps
straight to that detail page, pre-filtered to just that category.
This is the pattern that keeps a summary page uncluttered while still letting anyone go one level deeper on exactly the slice they clicked, without a separate slicer taking up space on the main page.
5. Publishing to Power BI Service
Home → Publish in Desktop signs in to a Microsoft account and
uploads the report to a chosen workspace in Power BI Service
(app.powerbi.com). Once there:
- The report opens in a browser, fully interactive, without Power BI Desktop installed.
- Individual visuals can be pinned to a Dashboard — a single-page, cross-report summary view.
- A report can be shared directly with specific people, or bundled with others into an App for a wider audience.
6. Scheduled Refresh & Row-Level Security
A published Import-mode report is frozen at whatever data existed at publish time until it's refreshed. In Service, the dataset's Settings → Scheduled Refresh sets one or more times per day for it to re-pull from the source automatically — a source that lives on-premises (a local SQL Server, for instance) additionally needs an On-premises Data Gateway installed so the cloud service can reach it.
Row-Level Security (RLS) lets one published report show different rows to different viewers automatically. Defined back in Desktop, under Modeling → Manage Roles:
[Region] = USERPRINCIPALNAME()
-- Assumes a Region column in the model holding each viewer's
-- email/UPN directly -- more commonly, a separate mapping table
-- ties USERPRINCIPALNAME() to a region, and the filter references that instead
After publishing, that role gets specific users or groups assigned to it under the dataset's Security settings in Service — from that point on, each assigned viewer opening the same report automatically sees only the rows their role's DAX filter allows, with zero separate reports to maintain.
7. Hands-on Exercise
Build and publish a one-page sales dashboard
Use Week 10's measures on top of Week 9's model.
Requirements:
- Build one report page with at least four visual types: a card (
Total Sales), a line chart (Sales YTDor monthly sales byMonth Name), a bar chart (sales by category), and a table (top customers). - Add a slicer bound to
Categoryor a date range, and confirm it filters the other visuals on the page. - Set at least one visual's interaction with another to None via Edit Interactions, and note why you chose that pair.
- Build a second, detail page and wire it up as a drill-through target for
Category. - Publish the report to a workspace in Power BI Service, and write two sentences describing what you'd configure next for scheduled refresh — even if you don't have a live gateway-connected source to actually schedule against.
A free Microsoft/Power BI account is enough to publish to "My Workspace" — a full organizational tenant with gateways and RLS role assignment usually needs a work or school account, so it's completely fine to describe the RLS/refresh configuration in writing rather than fully wiring it up if only a personal account is available.
8. Knowledge Check
Four quick questions. Expand each to check your answer.
Q1
Why is a bar chart usually a better choice than a pie chart for comparing 8 product categories?
Why is a bar chart usually a better choice than a pie chart for comparing 8 product categories?
A bar chart lets a viewer compare bar lengths, which the eye reads accurately even with many categories. A pie chart with 8 slices forces comparing angles — something people are reliably worse at judging — and the slices become visually cramped and hard to label clearly.
Q2
A KPI card should always show the company-wide grand total, even when a slicer on the page is active. How is that achieved?
A KPI card should always show the company-wide grand total, even when a slicer on the page is active. How is that achieved?
Set that slicer's interaction with the card to None via Format → Edit Interactions, so the slicer's filter simply doesn't reach that visual. (A measure written with CALCULATE(..., ALL(...)), from Week 10, achieves a related but different goal — ignoring filters inside the measure's own logic, everywhere it's used.)
Q3
What has to be set up on a detail page before it can be used as a drill-through target for Category?
What has to be set up on a detail page before it can be used as a drill-through target for Category?
The Category field needs to be dragged into the Drill through well in the Visualizations pane while that detail page is selected. Only then does right-clicking a category on a summary-page visual offer a "Drill through" option that jumps to the detail page pre-filtered to the clicked category.
Q4
An Import-mode report published to Service shows last week's numbers, even though the source database has new orders. What's missing?
An Import-mode report published to Service shows last week's numbers, even though the source database has new orders. What's missing?
A Scheduled Refresh (Dataset Settings → Scheduled Refresh) hasn't been configured, or hasn't run since the new orders arrived. Import mode always shows a snapshot from the last successful refresh — without a schedule (and, for on-premises sources, a working gateway), it stays frozen at whatever data existed when it was published.