Businesses still run on PDF. Invoices land in customer inboxes as PDFs. Contracts get signed, archived, and legally recognized as PDFs. Delivery notes, quotations, compliance reports, policy documents — the paperwork that leaves an organization is almost always in that format, because PDF is the universal "final copy" of a document. A platform that can turn its own canvas pages into print-ready PDFs closes a loop that otherwise requires an external document-generation tool, a separate templating system, and a maintenance burden that grows with every new document type.
The primary entry point is the create-PDF action in the automation builder. An automation can render a canvas page to PDF and then do whatever the workflow needs next — attach it to an email, store it in the file repository, send it as a webhook payload, or all three. The canvas page is the source, the PDF is the output, and the action is the one-line step that bridges them. That's important because it means PDF generation isn't a separate pipeline or a separate tool; it's part of the same automation surface where the rest of the workflow lives.
Under the hood, the platform offers two rendering paths, because different documents have different requirements. The headless-browser backend renders canvas pages the way a browser would — full CSS support, web fonts, images, complex layout, and the pixel-accurate fidelity that matters for branded documents. Invoices with a precise column layout, contracts with header and footer blocks, case reports with embedded visuals — all of these benefit from the headless-browser path because it understands modern layout the same way any web browser does. The template-based renderer is lighter and faster, suited to simpler documents that don't need complex CSS: form letters, standard reports, straightforward acknowledgments. Both paths are available; implementers pick the one that fits the document.
Configurable margins, headers, and footers are supported on the headless-browser path. Page numbers at the bottom. A branded header at the top of every page. Custom margins for documents that need to fit specific stationery or regulatory templates. All of these are configured at the canvas-page level and carried through to the PDF output. For documents that have to look a specific way — and invoices are a canonical example — the margin and header controls are what make the output genuinely print-ready rather than approximately print-ready.
Remote image support is a small but important detail. Images referenced by URL — hosted externally, served from a CDN, drawn from the media library — render correctly in the PDF. That matters because a document's imagery often lives somewhere other than with the document itself: a logo on a content-delivery network, a product image in a media library, a signature graphic from a remote asset store. The renderer resolves and embeds them transparently.
Character rendering is handled with care. Multi-script content — European languages with accented characters, Asian scripts, Cyrillic, Arabic — renders correctly using appropriate fonts. A PDF generated for a customer whose name is in a non-Latin script should have that name readable in the output; the platform handles font selection and embedding to make that happen. For international tenants, this is the detail that keeps generated documents from embarrassing themselves.
Any canvas page is a PDF target. This is worth sitting with for a moment. The same canvas page the user might view on screen — with all its data bindings, iterators, conditional rendering, and custom layout — can be rendered to PDF. Implementers build the document once as a canvas page and it serves two purposes: an on-screen view for users who want to inspect it in the application, and a PDF output for delivery. There's no separate PDF template to maintain; changes to the canvas page propagate to the PDF output automatically. That consolidation is genuinely a time-saver over the life of an implementation.
Email attachment is the most common downstream step. An invoice automation generates the PDF, attaches it to an email template, and sends the email to the customer — all in a single automation run. Because email templates and PDF generation live in the same automation builder, the coordination is natural: the email action accepts the PDF as an attachment directly, with no intermediate storage step required. The customer receives a branded email with the generated invoice attached. The tenant's workflow logs the whole thing.
Download from the UI is the other common path. A button on a record — configured through the automation builder — can render a PDF and hand it to the user for download. For workflows where users need the document on demand rather than waiting for a scheduled delivery, this is the right pattern. The user clicks, the document generates, the browser downloads it. No separate service, no tokenized URL to email anywhere.
Store-file as a subsequent action closes the archival loop. Generated documents can be dropped directly into the file repository, into the record they relate to, or into both. For compliance workflows where every generated document has to be retained, that automated storage is the difference between a manual archival step and a built-in one. The activity log and the version-management system both participate, so the generated document's history — created by this automation, sent to this recipient, stored in this folder — is fully recoverable later.
Worked example: invoice PDFs. The implementer builds a canvas page that renders an invoice — header block with branding, customer block bound to the invoice's customer reference, line-items table bound to the invoice's line-items replicator, totals block with computed fields, footer with payment instructions. An automation triggered when an invoice changes to Finalized status generates the PDF from that canvas page, attaches it to an email addressed to the customer, and stores the PDF in the invoices folder of the repository. The whole thing is canvas and automations — no custom templates, no external service.
Worked example: weekly reports. A scheduled automation runs every Monday morning, queries the last week's data, renders a summary canvas page to PDF, and emails it to a distribution list. The canvas page includes charts (dynamic areas), grouped tables (with calculations), and explanatory narrative text. The recipients see a professional report in their inbox; the report reflects the current data as of the moment it was generated; the whole mechanism is configured once and runs forever.
For tenants whose operations produce meaningful amounts of paperwork — invoicing, contracting, reporting, compliance — PDF generation is often the feature that eliminates the last piece of separate tooling. Combined with canvas, automations, email, and the file repository, it's everything needed to produce and deliver the documents that used to require a dedicated document-automation platform. That consolidation is quietly one of the most valuable outcomes of the whole feature set.