Product Decisions This Supports
- Audit trail: build vs. buy, settled cheaply. This package is a thin UI layer over
spatie/laravel-activitylog, which is already the de-facto Laravel standard for change capture. The buy decision is narrow but real: you are purchasing the timeline table, filters, old-vs-new diff rendering, restore action, navigation/authorization hooks, and ~20 community-contributed translations. The alternative is days-to-weeks of design and engineering plus permanent maintenance on screens no customer will ever call a differentiator. Scope it as infrastructure, not as a feature.
- Support and trust-and-safety operations. "Who changed or deleted this record, and what did it look like before?" is a recurring ticket class in every admin back office. A filterable view by causer, subject, event, and date turns those tickets into self-serve support-desk work. The v3.1.0
ListActivitiesByCauser page is the operationally valuable addition: pulling everything a given user did in a session directly supports impersonation investigations, offboarding reviews, and abuse triage.
- Compliance and procurement readiness. SOC 2 / ISO 27001 / GDPR-adjacent questionnaires consistently ask for evidence of administrative change tracking and access accountability. This gets you a defensible, demonstrable answer in the admin UI without a compliance vendor engagement. It is not a compliance-grade audit system on its own (see below), but it satisfies the "do you have one?" question and the day-to-day reviewer workflow.
- Forcing decisions you would otherwise defer. Standing the viewer up makes three implicit decisions explicit: which models and events get audited first (payments, role/permission changes, deletions, exports, impersonation), who may view the log, and whether restore is exposed at all. Restore is a genuine product and risk decision, not a checkbox — v1.1.0 extracted restore authorization into a dedicated policy hook precisely because "can view history" and "can rewind a record" are different permissions with different blast radii. This package gives you the seam to separate them.
- Roadmap risk on framework upgrades. Major versions track upstream majors: v2.0.0 added Filament v4 support, v2.1.0 added Filament v5, v3.0.0 moved to
spatie/laravel-activitylog v5. That cadence is a planning input — it means the audit UI is unlikely to be the thing that blocks a Filament upgrade, and it should be included in the upgrade checklist with a version pin rather than treated as a bespoke fork.
- Prioritization: buy the table stakes. Audit viewing scores low on differentiation and high on customer-expected. Buying it frees engineering capacity for the two or three things that actually move retention.
When to Consider This Package
Adopt when most of the following are true:
- You run a Filament admin panel and back-office/ops staff — not just engineers — need to read change history. This package is Filament-only; outside Filament it has no value, since Spatie provides the logging engine alone.
- You already use, or are willing to adopt,
spatie/laravel-activitylog v5. If you only need the event capture and no UI, use Spatie directly and skip this.
- You need localized, RTL-capable admin surfaces. Roughly twenty locales have been contributed (tr, id, nl, pt_BR, ckb, cs, fr, fa, es, it, ar, de, zh_TW, sk, and more) plus an RTL style fix in v2.0.2 — unusual maturity for a 233-star plugin and a real adoption criterion for non-English markets.
- Your team is small enough that owning a custom audit screen forever is a bad trade, and the data volumes are moderate (thousands to low millions of activity rows, paginated).
- You want restore capability available but gated, with authorization living in a policy rather than hardcoded.
Look elsewhere, or plan substantial additional work, when:
- You need tamper-evident or compliance-grade audit. This is a UI over a mutable database table. No cryptographic chaining, WORM storage, immutable retention, SIEM/syslog export, or formal retention/erasure policy. If an auditor requires non-repudiation or a regulator requires provable immutability, budget a dedicated audit pipeline in addition.
- You need analytics at scale. No partitioning, archival, or warehouse-sync strategy is evident. High-churn models will bloat the
activity_log table and slow the admin panel; plan for retention windows or off-box export from day one.
- PII is in the audited fields. Old/new values are stored in a JSON properties column, so deleted or corrected personal data persists in the log. You need a redaction and erasure story (attribute allow/deny lists per model) that this package does not give you out of the box.
- You need per-field or read-access auditing (who viewed a record, not just who changed it). Change-only capture will not satisfy that requirement.
- Bus factor is a blocker for your org. Effectively single-maintainer upstream with no listed dependents. MIT licensing and a small, shallow codebase make it forkable, so this is a pin-and-monitor risk rather than a disqualifier — but validate against your procurement standards before it becomes load-bearing.
How to Pitch It (Stakeholders)
For executives: We can close the "who changed this and what did it look like before?" gap in our admin back office in days rather than weeks, at zero licence cost, with no vendor lock-in. It turns a recurring class of support escalations into self-serve work for the ops team and gives us a credible answer to audit and security questionnaires about administrative change tracking. It is reversible — MIT-licensed, ~233 stars, a thin layer over a widely-used open-source logging library — and it is not the kind of thing customers buy us for, so buying it protects engineering time for what they do buy us for.
For engineering: It is a presentation layer, not a logging engine. pxlrbt/filament-activity-log renders spatie/laravel-activitylog v5 in Filament: a panel page, a reusable resource view component, filters by causer/subject/event/date, old-vs-new diffs, restore with a dedicated authorization hook, config published to the app, and translations already contributed. Integration is a composer require, a config publish, and a trait on the models we choose to audit. The real work is not the install — it is deciding model/event coverage, redacting sensitive attributes before they land in the properties JSON, setting a retention window, and separating "view log" from "restore record" permissions. Pin the major version (v3.x is the Spatie-v5 line, v2.x is the Filament-v4/v5 line) and add it to the Filament upgrade checklist, since its majors track Filament and Spatie majors. Keep the fork option open; the surface is small enough that we could own it if upstream stalls.