Product Decisions This Supports
- Build vs. buy for admin-side audit UI. This package is a Filament panel plugin that renders activity/audit-log records in the admin UI. The decision it informs is whether to spend engineering days building an in-house audit timeline view or adopt a community plugin as a thin presentation layer. If your team already uses
spatie/laravel-activitylog for the underlying data, this is a UI-only dependency and a comparatively cheap "buy."
- Roadmap sequencing for compliance and observability features. If "who changed what, when" is on the roadmap (SOC 2 prep, customer-facing change history, internal support investigations), a plugin like this can pull the feature forward by weeks — but only for internal admin consumption, not customer-facing audit exports.
- Feature scoping and non-goals. Adopting it lets you explicitly descope "build an audit log browser" from the roadmap and redirect that capacity to the higher-value work of actually instrumenting the domain events worth logging.
- Use cases it serves: support/CS triage ("why did this record change?"), internal QA and debugging, and lightweight internal compliance review. It does not by itself satisfy evidentiary audit requirements (tamper-proofing, retention policy, export controls) — that remains a separate workstream.
When to Consider This Package
Adopt (or pilot) when all of the following hold:
- You run Filament for internal/admin surfaces and want activity history surfaced without custom Blade/PHP work.
- You already capture activity via a logging package (typically
spatie/laravel-activitylog); this is the viewer, not the recorder.
- The consumer is internal staff, and a "good enough" audit timeline is acceptable.
- You can absorb API churn: this is a 0.0.x release, which under semver means no stability guarantees whatsoever.
Look elsewhere — or build in-house — when:
- You need a stable public API or long-term support. Treat every 0.0.x bump as potentially breaking until it reaches 1.0. The v0.0.2 release shipped with no documented changes beyond a compare link, which is itself a signal about release hygiene and how much you can rely on upgrade notes.
- You need auditability guarantees: immutable storage, retention/legal hold, exportable evidence, or access controls beyond what the host panel provides.
- You are not on Filament, or you are on a Filament major version the plugin hasn't been validated against.
- You have single-maintainer risk tolerance of zero, or your procurement process requires a support contract, security review artifacts, or a published deprecation policy.
- Your audit volume is high enough that UI rendering over the activity table becomes a query-performance concern.
How to Pitch It (Stakeholders)
To executives: This is a small, low-cost admin plugin that gives our internal team a ready-made "history" view for records — who changed what, and when — instead of us building one. It saves roughly a sprint of UI work and supports the audit-trail story we're telling for compliance readiness. The trade-off is maturity: it's a pre-1.0, single-maintainer open-source package, so we'd treat it as an internal-tooling convenience, not a compliance control, and we should budget a small amount of maintenance to keep pace with its releases. Recommended path: time-boxed pilot in a non-critical admin panel, revisit at 1.0.
To engineering: It's a presentation-layer Filament plugin over activity-log data we're already collecting — minimal surface area, no schema ownership, and low lock-in: if we drop it, we lose a UI, not data. Caveats to plan around: the 0.0.2 release carried no changelog detail, so pin the version, review diffs before upgrading, and wrap any direct usage so a breaking change is a one-file fix. Do not treat it as a substitute for logging instrumentation or for retention/immutability guarantees downstream.