Filament Record Pdf Laravel Package

Product Decisions This Supports

• Build vs. buy for document generation. Per-record PDFs are commodity output, not differentiated product. This package supplies the whole job (render, cache, authorize, download, email, save, bulk ZIP) behind ~10 configurable methods, so the build-vs-buy answer defaults to buy/assemble and redirect engineering toward the parts customers actually judge: the document design and the data inside it.
• Shipping an export story without a roadmap cycle. "Invoices / statements / receipts / compliance exports" is usually a quarter-shaped epic. Here it is a per-resource Blade view plus five actions, which makes it viable to attach PDF output to two or three resources in one sprint and measure usage before committing further.
• Sequencing the export surface. The five actions map to distinct product bets that can ship in tiers rather than all at once: Preview (lowest risk, no artifact leaves the app), Download (baseline expectation), Bulk ZIP (power-user / month-end workflows, queue-backed above a configurable threshold), Save to disk or media library (retention, audit trail, "documents" as a first-class object in the product), Email (customer-facing communications — the biggest brand, deliverability and abuse surface, and the one to gate last).
• Where exports live in the UX. Because actions are per-record and also usable as header actions on the view page, the same capability can be offered from the table row, the record page, or a bulk selection without new backend work. That is a genuine product decision this package makes cheap to test rather than a technical detail.
• Governance and PII posture, decided up front. Per-record policy checks (viewPdf / downloadPdf / emailPdf / savePdf, falling back to view / update) mean export entitlements can be aligned with existing record permissions instead of becoming a shadow permission system. This is the decision that lets legal/security sign off on generating documents containing customer data.
• Infrastructure and cost trade-offs made visible. Driver choice is per-action or global config: pure-PHP dompdf (no headless browser, cheap, CSS-limited) versus Browsershot/Chrome/Gotenberg/Cloudflare/WeasyPrint (design fidelity, real memory and container cost). That is a per-document-type product decision — a plain internal report and a customer-branded invoice do not need the same renderer.
• Retention and "document as record." SavePdfAction with an optional column target or a spatie/laravel-medialibrary collection, plus overwrite(false) to preserve prior versions, is enough to support statements like "every issued invoice stays retrievable" without a bespoke storage design.
• Deferring the hard parts deliberately. Filament 4/5 only, and PDFs as a presentation layer over existing Filament resources, means the package does not force a document-management domain model. Fine for an export feature; a signal to look elsewhere if documents become the product.
• Risk items to log rather than discover. v1.0.0, first release, single maintainer; queue-backed bulk export requires a working queue worker and notification delivery in the target environment; the 10-minute cached preview behind a user-bound signed URL is sensible but should be reviewed against your data-retention policy; emailing to up to 10 recipients needs rate limiting and abuse controls at the app layer.

When to Consider This Package

Adopt when most of the following hold:

• The application is Filament 4 or 5 and the records to be exported already exist as Filament resources with policies. The package's whole value proposition is that it plugs into that surface; outside Filament it is not applicable.
• The output is a record-shaped document — invoice, receipt, statement, certificate, order confirmation, per-customer report — rather than an arbitrary data dump. If the need is "export this table to CSV/XLSX," this is the wrong tool.
• Documents are a supporting feature, not the product. If PDF fidelity is a brand-critical deliverable reviewed by design, budget for Chrome/Browsershot or Gotenberg as the driver and treat dompdf as the development default only.
• You want authorization to inherit from existing policies and can express export rights in terms of view/update or dedicated abilities. This is the strongest adoption signal for regulated or B2B contexts.
• You need bulk export without building a job pipeline, and can accept the queue-plus-database-notification pattern above the configurable threshold (default 25 records).
• The team is comfortable with spatie/laravel-pdf and Blade as the templating layer, including the make:record-pdf-view scaffold and the provided generic attribute-listing view as a starting point.

Look elsewhere, or plan to build, when:

• You are not on Filament, or are pinned to Filament 3 or earlier.
• You need pixel-perfect, design-owned layouts and are unwilling to run a headless browser. dompdf will not deliver modern CSS layout, and the resulting iteration cost lands on design and QA, not on this package.
• You need long-term vendor stability — a first-release, single-maintainer package is a reasonable dependency for an export feature, not for a system of record. Have an exit plan: the underlying spatie/laravel-pdf calls are ordinary Laravel code, so forking or reimplementing the action layer is bounded work.
• You need document lifecycle management — templating versioning, e-signature, archival/WORM storage, redaction, or multi-document packet assembly. That is a domain product, not an action set.
• No queue worker is available in the deployment and bulk export above the threshold is a requirement; you would be relying on a path that silently degrades or fails.
• Your email channel is already complex — marketing automation, per-tenant sending domains, deliverability monitoring. The built-in email action is a convenience, not a replacement for that infrastructure.

How to Pitch It (Stakeholders)

For executives. This closes a recurring customer request — "can I get a PDF of this?" — for roughly the cost of writing a template per document type instead of building an export subsystem. It covers the full expected arc (preview, download, email, save, bulk ZIP) with permissions tied to records users can already see, so it does not create a new way to leak customer data. It ships on a pure-PHP renderer with no browser infrastructure by default, keeping run cost near zero, with an option to upgrade fidelity for customer-facing documents only. The honest caveats: it is a new v1.0.0 from a single maintainer, and it only fits our Filament admin surface — appropriate for an export capability, not for anything we would call a document platform.

For engineering. A thin, opinionated action layer over spatie/laravel-pdf: five Filament actions, ~10 shared configuration methods (pdfView, pdfData, pdfFilename, pdfFormat, pdfLandscape, pdfDriver, modifyPdfUsing, pdfAbility, authorizePdfUsing), per-record policy checks, and driver selection per action or by config. The parts we would otherwise get wrong are handled: preview files are rendered once, cached 10 minutes and served via a signed, user-bound URL with the download reusing the same artifact; filenames are reduced to [a-z0-9-] plus .pdf and save directories are validated as relative and traversal-free; dompdf is pinned to a patched floor (>= 3.1.6) after six 2026 advisories. Bulk export above 25 records moves to the queue and returns a signed, expiring link via database notification — so the deployment needs a worker. Testing is better than typical for a first release: Pint, PHPStan level 5, 67 Pest tests across PHP 8.2–8.5 × Laravel 12/13 × Filament 4/5, lowest-supported dependency pins, plus a 44-check headless-Chrome UI pass on fresh installs in light and dark. Recommended first step: wire it to one low-risk internal resource with the dompdf driver, confirm the worker and notification path in staging, then evaluate a Chrome/Gotenberg driver against a branded customer-facing template before enabling the email action broadly.