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-paginated-reports.md
feature-paginated-reports.mdv1 · history
CurrentApplies to BothUpdated last monthSource Microsoft Learn ↗

What it does

Paginated reports are .rdl reports built in Power BI Report Builder and published to the Power BI service. They lay out every row of a table across as many printed pages as it takes, with exact control of page layout, repeating headers and footers. Microsoft's own example runs to 563 pages, one per invoice.

Key facts

  • Authored in Power BI Report Builder, a separate free download. It shares its foundation with the tools used for SQL Server Reporting Services and Power BI Report Server.
  • Licence requirements match ordinary Power BI reports. A free licence publishes to My Workspace only; Pro or PPU publishes to other workspaces, and you need at least Contributor on the workspace plus Build permission on the dataset.
  • No underlying data model. Data sources and datasets are embedded in the report itself. A single paginated report can use several different sources.
  • Supported sources include Azure SQL Database and Azure Synapse Analytics, Azure Analysis Services via SSO, SQL Server via a gateway, Power BI semantic models, Oracle and Teradata.
  • Export formats from the service: HTML, MHTML, PDF, XML, CSV, TIFF, Word and Excel.
  • Email subscriptions are supported — hourly, daily or weekly — delivering a PDF attachment of the whole report.
  • Works with deployment pipelines (Development, Test, Production) and with sensitivity labels applied in the service.
  • Reports built for SSRS 2016 or later, or for Power BI Report Server, are compatible with the Power BI service, though not every feature carries across.
  • Not supported: shared data sources and shared datasets (.rds/.rsd), data-driven subscriptions in the service, pinning pages or visuals to dashboards, and document maps (they don't render in the service but do on export).
  • Memory limits vary by licence type and apply to rendering and export. Microsoft doesn't publish the specific figures in this article and directs you to your admin or support.

When to use / skip

Reach for paginated when the output is a document rather than a screen — invoices, statements, regulatory returns, picking lists, anything that gets printed, signed or filed. The deciding test is simple: put a long table in an interactive report, export it, and you get only the rows that fitted on screen. Put the same table in a paginated report and you get all of them. Skip paginated for anything exploratory. It has no model, no cross-filtering and no interactivity worth the name, and building one is closer to Reporting Services development than to Power BI report authoring. Most clients need a handful of paginated reports and a lot of interactive ones.

Configuration decisions

  • Data source strategy: query a Power BI semantic model to reuse the existing measures, or hit the source directly with SQL for control and speed.
  • Layout type — table, matrix, chart or free-form list — which the Report Builder wizards start you off with.
  • Parameters and filters, which is how a single report definition serves many recipients.
  • Whether distribution is on-demand viewing, subscriptions with PDF attachments, or embedding.
  • Whether an on-premises source needs the connection redirecting through a gateway after upload.
  • Whether the reports go through deployment pipelines like the rest of the estate.

Gotchas

  • Report Builder is a different tool with a different skill set. Budget for that, or find out mid-project when nobody on the team can write an RDL expression.
  • No shared data sources or shared datasets means connection details are embedded per report. Fifty reports means fifty places to change a server name.
  • Memory limits surface as failed exports on the largest reports, which is exactly where paginated is being used, and the limits aren't published in the main article.
  • Data-driven subscriptions don't exist in the service. Clients migrating from SSRS often depend on them heavily and it's a genuine gap.
  • Document maps render on export but not in the service, so a report looks broken in the browser and fine as a PDF.
  • Dashboard pinning from paginated reports in the service isn't supported, and the on-premises path for it is a discontinued feature.

Consultant notes

  • Frame paginated reports as the operational-document tool alongside Power BI's analytical tools. Clients grasp "invoices and statements versus dashboards" immediately.
  • On SSRS migrations, audit for data-driven subscriptions and shared datasets early. Those are the two things that don't come across, and they're usually load-bearing.
  • Reuse the semantic model as the data source where you can. It keeps one definition of the measures rather than reimplementing them in SQL.
  • Get a realistic volume test in before go-live. The reports that matter are the long ones and those are the ones that hit memory limits.

Revisit if the client migrates more from SSRS, or once Microsoft publishes clearer per-licence memory limits.

Was this accurate?
Related
Power BI in Microsoft Teams07-embedding-and-integrationXMLA endpoint09-alm-and-deploymentSemantic model fundamentals01-semantic-modelsPower BI vs native Dynamics 365 reporting11-decision-guidesSubscriptions and alerts05-service-and-workspacesSensitivity labels08-governance-and-security