Almanac
Microsoft/power-biPower Platform

Consultant KB for Microsoft Power BI: semantic models, DAX and modelling, Power Query and dataflows, reports and visuals, the service and workspaces, capacity and performance, embedding and integration, governance and security, ALM and deployment, and licensing, plus cross-cutting decision guides. Scoped to Power BI, with Microsoft Fabric covered where it touches Power BI directly. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power BI release plans, docs repo and product blog, plus the author's own consultant notes.

power-bi/04-reports-and-visuals/feature-report-design-fundamentals.md
feature-report-design-fundamentals.mdv1 · history
CurrentApplies to BothUpdated last monthSource Microsoft Learn ↗

What it does

Report design in Power BI is the set of decisions about canvas size, page structure, navigation and consistency that sit above any individual visual. Canvas settings in the Format pane control aspect ratio, dimensions and vertical alignment for each page.

Key facts

  • Default display ratio is 16:9. The first page of a report keeps the older 1280x720 default; newly added pages default to 1920x1080.
  • Canvas size is per page, not per report. A tooltip page and a standard page live in the same file at different sizes.
  • Page size templates include the Tooltip preset, which gives a canvas sized for hover use.
  • Dashboards are a Power BI service feature and don't exist in Desktop. A dashboard is a single canvas; a report can have many pages.
  • A report draws on one semantic model. A dashboard can pin visuals from several different semantic models onto one canvas.
  • Dashboards don't support filtering or slicing, but they do support Q&A natural language queries and data alerts.
  • Visual defaults let you set formatting once at report level rather than per visual, which is how you keep a multi-page report consistent.

When to use / skip

Design decisions get made whether or not anyone makes them deliberately, so make them at the start. Fix the canvas size before the first visual goes on the page — resizing later reflows everything and someone spends a day nudging boxes. Use a dashboard when the ask is genuinely "one screen, headline numbers, from more than one model"; use a report for anything where people need to filter, explore or drill, which is almost everything. If the client asks for a dashboard, check whether they mean the product feature or just "a page with the important numbers on it" — nine times out of ten it's the latter and a report page is the right answer.

Configuration decisions

  • Canvas size and ratio, agreed against the devices people will actually use, including whether mobile layout is in scope.
  • Page architecture: overview, detail, drillthrough targets, tooltip pages, and which of those are hidden from the page tab strip.
  • Navigation model — page tabs, buttons, or a bookmark navigator — and whether it's consistent across pages.
  • A report theme, set up once, so colours and fonts aren't chosen visual by visual.
  • Which elements are fixed furniture (header band, slicer rail, filter pane position) and hold the same position on every page.
  • Whether the filter pane is visible, collapsed or locked for consumers.

Gotchas

  • The first-page-versus-new-page size default difference bites quietly. Pages that look identical in Desktop render at different scales in the service.
  • "Fit to page" in Desktop hides sizing problems. Switch to Actual Size before you sign off any layout.
  • Slicers keep filtering whether or not they're visible. A slicer hidden behind an image is still doing work, and nobody can see why the numbers are wrong.
  • Exports to PDF and PowerPoint follow canvas size, so a wide custom canvas produces a document nobody can read.
  • Reports built at one resolution on a developer's ultrawide monitor look cramped on a 1366x768 laptop, which is what the finance team has.

Consultant notes

  • Get sign-off on a single page layout before building the rest. Twelve pages of a layout the client dislikes is an expensive way to discover it.
  • Design for handover: consistent naming for pages, bookmarks and visuals, and no orphaned hidden pages. The next person inherits your habits.
  • Push back on the "one page with everything" request. Page count is free; visual clutter isn't, and too many visuals on a page also slows rendering.
  • Agree early who owns the theme file. Without an owner every new report reinvents the colour palette.

Worth another look when new page-size defaults change again, or if the client standardises on a different device profile.

Was this accurate?
Related
Drillthrough and report page tooltips04-reports-and-visualsPower BI in model-driven apps07-embedding-and-integrationPaginated reports04-reports-and-visualsPower BI on Dynamics 365 dashboards07-embedding-and-integrationPower BI vs native Dynamics 365 reporting11-decision-guidesPower BI mobile apps05-service-and-workspaces