Filament Auditing Laravel Package

Product Decisions This Supports

• Compliance and audit-trail roadmap. Surfaces owen-it/laravel-auditing records inside the Filament admin panel, so "who changed what, when, and from where" becomes a product capability we can demo to security reviewers rather than a database query an engineer runs manually. Directly relevant to SOC 2 / ISO 27001 evidence, GDPR/CCPA subject-access requests, and internal incident review.
• Build vs. buy on admin tooling. The alternative is a bespoke Filament resource over the audits table (a few days of engineering plus ongoing maintenance). Adopting this package is the cheaper path if our audit needs stay generic — a custom viewer is justified only when we need domain-specific diff rendering, redaction rules, or cross-tenant scoping the package does not provide.
• Feature scoping for record history UX. Because it consolidates the audit view into a single Filament action (v2.0.0), the design question shifts from "do we build a history screen?" to "where do we mount one action per resource, and do we expose old/new values to non-admin roles?" That is a small, bounded scope decision we can make now.
• Upgrade sequencing decision (new in v2.0.0). Filament v4 is now the minimum. This makes "upgrade Filament" a hard prerequisite for any audit-UI work, and it forces a fork in the roadmap: stay on v1.1.0 with Filament v3, or bundle the Filament v4 migration with the auditing feature. The two must be planned together, not separately.
• Use cases worth validating with customers: per-record change history in support tooling, "last modified by" trust signals for finance/ops users, and dispute resolution where a customer claims a record was altered.

When to Consider This Package

Adopt when:

• The product already runs Filament v4 or plans v5 — v2.0.0 will not install on v3, so this is non-negotiable.
• Audit data already lives in (or can live in) the standard laravel-auditing audits table. If audit capture is not yet instrumented, that work is a prerequisite the package does not do for you.
• The need is internal visibility — support agents, ops, finance, or admins reviewing history inside the panel. This is an admin-UX package, not an audit pipeline.
• The team values low integration cost over deep customization: the value proposition is a pre-built Filament action over data we already store.

Look elsewhere or build in-house when:

• We are pinned to Filament v3 with no near-term upgrade. Use v1.1.0 knowingly, or defer. Note that staying on v1.1.0 means accepting an unmaintained branch — a real risk for a compliance-adjacent dependency.
• Requirements include tamper-evident or append-only logging, external SIEM export, retention policies, or log shipping. laravel-auditing plus a viewer is not an immutable audit log; if a compliance framework demands WORM storage, this package is the wrong layer.
• We need fine-grained access control, redaction of PII in diffs, or multi-tenant isolation in the history view. Confirm these exist before committing; the release notes give no indication either way.
• We are not on Filament at all, or the audit trail must be exposed to end customers through a public API rather than an admin UI.

Risk notes to close before committing: the v2.0.0 notes are thin — "probably also need to do other changes to better integrate Filament v4 but that can come later" signals an incomplete migration and a maintainer working without a formal support commitment. The changelog is dominated by Dependabot bumps, so the substantive surface area of this release is one PR. There is no stated support policy, LTS, or security disclosure process. Verify release cadence, open-issue responsiveness, and license before treating it as infrastructure — treat it as a convenience dependency, and keep the escape hatch (a native Filament resource) cheap by not letting audit UI assumptions leak into other code.

How to Pitch It (Stakeholders)

Executives / sponsors: This is a small, low-cost plugin that puts an audit trail inside our admin panel — it answers "who changed this record and when" for support, finance, and compliance reviewers without a custom build. The catch: the new 2.0 release requires Filament v4, so it is gated behind an admin-framework upgrade we would need to schedule anyway. Recommendation: fund the Filament v4 upgrade, and take the audit UI as a rider on that work rather than a standalone project. Treat it as a convenience, not a compliance control — it displays history, it does not guarantee immutability.

Engineering: v2.0.0 is a breaking major. Filament v4 is now the floor (v5 supported), and the per-record history has been consolidated onto a single Filament action, so any resource integrations need rewiring. Existing Filament v3 apps cannot upgrade and should stay on v1.1.0. The release notes explicitly admit the v4 integration is not finished ("other changes... can come later"), so budget for us to verify behavior in our own panel before rollout — particularly action placement, diff rendering, and whether old/new values are exposed to roles that should not see them. Effort is small, but do not treat this as a drop-in.

Product: Scope stays narrow and that is the point — one history action per resource, populated from laravel-auditing. Before we commit, we need three answers: which resources get the action, which roles may see field-level diffs, and whether any audited field contains PII that must be redacted. If the answers require per-field redaction or tenant-scoped history, we should evaluate a custom resource instead, because this package does not advertise that capability.