Paginated reports have always occupied a distinct and important role in the Power BI ecosystem - producing print-ready, precisely formatted outputs with complete data rendering that interactive Power BI reports are not designed to deliver. The friction has been in their creation: until recently, building a paginated report required Power BI Report Builder, a separate desktop application with its own learning curve, installation overhead, and authoring model that diverges significantly from the Power BI Desktop experience most developers already use. The new Power BI paginated report authoring experience removes that friction by bringing paginated report creation directly into the Power BI service browser interface, under the same workspace and tooling model that governs everything else in the Power BI ecosystem.

Why Report Builder Created a Workflow Gap for Enterprise Teams

Power BI Report Builder is a capable tool for producing complex paginated report layouts nested tables, sub-reports, complex expressions, and precise print margin control are all within its scope. The problem for enterprise teams is operational rather than technical. Report Builder requires local installation, meaning developers working on shared or managed devices need IT intervention to provision it. It operates outside the Power BI service, meaning that publishing, versioning, and collaboration follow a different workflow from standard Power BI reports. And its interface, derived from the older SQL Server Reporting Services designer — is unfamiliar to developers whose primary experience is Power BI Desktop.

The consequence in practice is that paginated reports are often underutilised or avoided even in scenarios where they are the technically correct output type. Finance teams that need a precisely formatted multi-page invoice report, HR teams that need a complete employee register in a fixed-width PDF layout, and operations teams that need a pixel-perfect regulatory return, all of these use cases are better served by a paginated report than by a standard Power BI table visual, but the Report Builder barrier has historically led teams to use table visuals instead and accept the formatting limitations that come with them.

What the New Paginated Report Authoring Experience Delivers

The new Power BI paginated report authoring experience is a browser-based designer built into the Power BI service. It allows developers to create and edit paginated reports directly within a workspace, using a drag-and-drop layout interface that is consistent with the general Power BI service design language. Reports created in this experience connect to Power BI semantic models and other Fabric data sources through the same data connectivity model used by standard reports. Finished reports can be saved to the workspace, shared with report consumers through standard Power BI distribution channels, and exported to a range of output formats including PDF, Excel, Word, CSV, and PowerPoint.

The experience is designed for the most common paginated report authoring tasks multi-page tabular layouts, formatted headers and footers, consumer-facing parameters, and text and image elements - without attempting to replicate the full RDL expression language and layout complexity of Report Builder. For organisations whose paginated report requirements fall within this scope, the new experience removes the need for Report Builder entirely. For organisations with highly complex report definitions that require sub-reports or advanced RDL expressions, Report Builder remains available and the two tools coexist within the platform.

The Editor and Preview Split: How the Interface Works

The new Power BI paginated report authoring interface is structured around two complementary panes that developers switch between during the design process. The Editor pane is where the report definition is built and modified, adding data fields to table regions, configuring column widths and sort orders, placing text elements, and setting parameter definitions. The Editor operates against the report's schema rather than rendering live data, which keeps the authoring environment fast and responsive even when the underlying dataset is large.

The Preview pane renders the report as it will appear when consumed applying the actual data from the connected semantic model or data source, paginating the output across pages, and displaying the parameter pane when parameters have been defined. The Preview is updated on demand rather than in real time, allowing developers to make multiple layout changes in the Editor before rendering to check the visual output. This Editor/Preview split is a deliberate design choice that mirrors how Report Builder has always worked, making the transition familiar for developers who have used the desktop tool while maintaining the performance characteristics needed for a browser-based experience.

How to Create a Paginated Report in the Power BI Service

Creating a paginated report in the new experience starts from the workspace where the source semantic model or dataset is stored. The creation workflow is integrated with the standard Power BI service workspace interface and requires no additional tools or installations.

1. Open your workspace navigate to the Power BI service workspace that contains the dataset or semantic model you want to use as the data source for the paginated report. Locate the file in the workspace content list.
2. Initiate paginated report creation click the three-dot options menu on the semantic model item. From the dropdown, select Create paginated report. This opens the new browser-based authoring experience directly, pre-connected to the selected semantic model as the data source.
3. Design in the Editor — in the Editor pane, add fields from the data source to the report's table regions by dragging them from the field list. Configure column headers, adjust widths, set sort orders, and add any required text boxes or image elements to the report body.
4. Add headers and footers from the Insert option on the ribbon, add a header and/or footer to the report. Insert page numbers, execution timestamps, text content, or images as required for the output format.
5. Create parameters if needed for reports where consumers need to filter the output on demand, open the filter pane in the Editor, select the three-dot menu on the field to be parameterised, and choose Create parameter. The parameter pane will appear in the Preview for consumer use.
6. Review in the Preview switch to the Preview pane to see the rendered report against live data. Check pagination, column alignment, header and footer placement, and parameter behaviour before saving.
7. Save and share use File → Save on the ribbon to save the paginated report to the workspace as a new report item. The saved report is then shareable through standard Power BI service distribution workspace access, app inclusion, or direct link sharing.

Adding Headers, Footers, and Page Elements

Headers and footers are a fundamental requirement for print-ready and PDF-format paginated reports. A financial statement that does not carry a page number and report title on every page, or a regulatory return that omits the execution timestamp, does not meet the presentation standards that these output types require. The new Power BI paginated report authoring experience supports both through the Insert ribbon option, which surfaces a dedicated header and footer configuration pane.

From the Insert panel, developers can add page numbers configured with a standard page numbering expression that increments automatically across rendered pages alongside execution time stamps that display when the report was generated. Text boxes within the header or footer accept static labels, such as report title, organisation name, or confidentiality classification, and can be positioned precisely within the header or footer band. Image elements allow corporate logos or branding assets to be embedded in the header, satisfying brand compliance requirements for externally distributed reports without post-processing in a third-party application.

Creating and Using Parameters for Consumer-Driven Filtering

Parameters in paginated reports serve a fundamentally different purpose from slicers in standard Power BI reports. A slicer filters data already loaded into the report page; a parameter in a paginated report controls the query sent to the data source, meaning only the data that matches the parameter value is retrieved and rendered. For large datasets, this distinction has significant performance implications, a paginated report parameterised by date range, region, or product category retrieves only the relevant slice of data on each render rather than loading the full dataset and filtering it in memory.

In the new authoring experience, parameters are created directly from the filter pane without requiring expression syntax or manual RDL editing. The developer selects the three-dot menu on any field in the filter pane and chooses Create parameter. Once created, the parameter appears as an input field in the Preview pane's parameter bar, where the developer can test different values before publishing. Report consumers see the same parameter bar when they open the published report, and they control which data is rendered by entering or selecting their parameter values before the report generates. For reports distributed to finance, compliance, or operational teams who need to run the same report for different entities or time periods, this self-service parameter model removes the need for developers to maintain separate report versions for each entity.

New Authoring Experience vs. Power BI Report Builder: A Comparison

When to Use Paginated Reports vs. Standard Power BI Reports

The new Power BI paginated report authoring experience makes paginated reports more accessible, but the underlying distinction between paginated and standard reports remains important for developers making the right format choice. The two report types are optimised for different analytical and distribution use cases, and the new authoring experience does not change those fundamentals.

Standard Power BI reports are designed for interactive analytical exploration slicing, filtering, drilling, and cross-highlighting across visuals on a canvas. They load a data snapshot and allow consumers to explore it dynamically. They are appropriate for dashboards, operational monitoring, self-service analytics, and any scenario where consumer interaction with the data is the primary purpose.

Paginated reports are designed for fixed-format, complete-data output every row that matches the query parameters is rendered, regardless of volume, in a precisely controlled layout that is optimised for printing or export. They are appropriate for invoices, statements, compliance reports, operational registers, and any scenario where the report will be exported to PDF or printed, where precise column alignment is required, or where the consuming system requires a structured data export like Excel or CSV with a defined schema.

Next Steps for Your Paginated Reporting Programme

For organisations that have avoided paginated reports due to the Report Builder barrier, the new Power BI paginated report authoring experience is a practical prompt to revisit use cases that have been handled with standard Power BI table visuals as a workaround. Any report that is regularly exported to PDF or Excel by consumers, any report that needs to render all rows rather than a display-capped subset, and any report that requires a controlled print layout with headers, footers, and page numbers is a candidate for migration to a paginated format.

For Power BI centres of excellence and enterprise BI consulting teams, the new authoring experience also lowers the skill threshold for paginated report development significantly. Report developers who are competent in standard Power BI report authoring can now produce well-structured paginated reports using the same service environment they already use daily, without the RDL learning curve that Report Builder required. This makes it practical to include paginated reports in standard report delivery templates for use cases where they are the appropriate output type.

To discuss how the new paginated report authoring experience fits into your Power BI reporting strategy, or to get support building a paginated report library for finance, compliance, or operational distribution, speak with a certified Power BI consultant at Numlytics. For related Power BI reporting topics, see our guides on the Power BI data limit feature for performance governance and Power BI visual level format strings.