Document reports — print formats for records

Q: How do I put a Print button on invoices?

Two pieces. First, build the document report: Reports → New Document Report , define the data over the invoice entity (joining the customer and the invoice lines), then lay out the form in the designer — the full walk-through is in the report designer guide . Second, have an administrator add a Print action on the invoice entity that references that report, and share the report with the users who will print. From then on the button renders the current invoice and opens the print dialog; the same action on the invoice list prints the selected invoices as one PDF.

A document report is the third report format: not an interactive grid or a pivot but a designed, paginated document — an invoice layout, a purchase-order form, a delivery note, a payslip, a statement. Its data comes from the same wizard as every other report; its appearance is drawn in the full report designer, band by band, so the output is print-grade and deliberate. What makes document reports distinctive is where they run: mostly not from the report library, but from the records they describe.

Reports library filtered by the word Invoice: rows typed Document Report (Bulk Invoice Print, E-Invoice Document Report, Invoice Print and Preview Document Report, Invoice Document Print) alongside rows typed Report, with the New Document Report action in the page header — Document reports live in the same Reports library as grid reports; the Type column tells them apart, and New Document Report in the header is where a new print format starts.UI captured 2026-09-06

In the Reports library a document report is an ordinary row whose Type reads Document Report (a grid report reads Report). The page header offers three starts — New for a grid report, New Document Report for a print format, New Pivot Report for a pivot — and the library's folders, favourites and subscriptions apply to all three alike.

Two halves: data and layout

Every document report has a data definition and a layout.

Data is built in the wizard, which titles this pass Document Report Data and walks eight steps: Data Source (the primary entity and its related entities), Relationships, Fields, Columns, Display Grouping, Display Summary, Filters and Details. Next stays disabled until the current step has what it needs — a primary entity first of all.
Layout is built in the banded report designer: page bands, headers and footers, detail rows, groups and totals, images and labels.

The split shows up in the Setup analytics screen as two separate row actions — Edit Report for the data, Design Report for the layout — and in practice as two different skills: the data half is query thinking, the layout half is page design.

Where document reports surface

On records, as Print and Preview actions. This is the main stage. An administrator adds an action of type Preview or Print to an entity under Design Studio → Entities → the entity → Logic → Actions, and the action form asks for the document report to render. When a user runs the action, the current record's identifier is passed to the report as its Id parameter, so the layout renders just that record. Preview opens the rendered PDF in a viewer inside the page; Print renders it and hands it straight to the browser's print dialog.
From lists, for selected records. The same actions run from a list over the selected rows, passing every selected identifier. The records are rendered into one PDF with each record starting on a fresh page — which is what a Bulk Invoice Print format is for. An action can be marked as requiring a selection, in which case running it with nothing selected prompts for one instead of rendering everything.
In the report library. A document report you can see is listed under Reports like any other and opens in a paginated viewer with page navigation, zoom, Print and Export. Run this way — without a record context — it renders whatever its own query and filters return; a report whose query returns nothing shows an empty document rather than an error.
In subscription emails. A subscription to a document report exports the designed layout on schedule, so the attachment matches the printed form.

Access follows the report rules

A document report is a report: the visibility rule decides who sees it in the library, and it starts private to its creator. Wire it to a record action and share it with the users who run that action — an unshared print format is the classic reason a Print button works for the administrator who built it and fails for everyone else. The record action itself is also permissioned like any custom action: the user's profile must grant it.

Common questions

How do I put a Print button on invoices?

Two pieces. First, build the document report: Reports → New Document Report, define the data over the invoice entity (joining the customer and the invoice lines), then lay out the form in the designer — the full walk-through is in the report designer guide. Second, have an administrator add a Print action on the invoice entity that references that report, and share the report with the users who will print. From then on the button renders the current invoice and opens the print dialog; the same action on the invoice list prints the selected invoices as one PDF.

Can one document report serve several entities?

A document report is built over one primary entity — its query starts there, and record actions pass identifiers of that entity's records. Related data comes in through relationships (an invoice layout routinely prints customer fields and line items), but for genuinely different documents — an invoice form and a purchase-order form — build one document report each.

What's the difference between a document report and exporting a grid to PDF?

A grid export is the table, as rendered: columns, rows, whatever you filtered. A document report is a designed page: headers and footers where you put them, one record per document if that is the design, logo, addresses, totals in the right corner. Use exports to move data; use document reports when the page itself is the deliverable.

Why does the report open empty from the library but print fine from a record?

Because the library run has no record context. The report's own filters decide what it returns, and a layout designed around a single record often has a filter that matches nothing until an Id is supplied. That is expected; test print formats from the record action, not from the library.