Nova Activitylog Laravel Package

Product Decisions This Supports

• Whether audit visibility is a real internal need or a hypothetical one. This package is the cheapest possible way to find out. It puts "who changed what, when" in front of support and security staff inside Laravel Nova, so you can measure adoption — are tickets actually resolved faster, do support engineers open the panel in week one — before funding anything larger. Treat it as a time-boxed spike with a kill criterion, not a roadmap commitment.
• Build vs. buy for internal admin UX. If the requirement is read-only browsing with filters (log name, event, subject, causer, date) and a property-diff viewer, a thin community Nova screen beats building a custom audit resource. The moment requirements drift toward export, alerting, immutability, legal hold, or customer-facing access, the calculus flips and you should scope a real feature.
• Audit semantics — a product decision the package cannot make for you. Which models and events get logged, what counts as a meaningful change (logOnlyDirty, dontSubmitEmptyLogs), and who is attributed as causer are all product scope. Getting the domain-level naming convention right (billing / auth / admin / integrations rather than model class names) determines whether the panel is useful in six months or becomes an unreadable stream of empty diffs.
• Retention and access policy. Spatie's activitylog:clean makes data retention a configurable knob, which means it's a decision you own with security/legal — not a default you inherit. Likewise, the panel's authorization is all-or-nothing unless you scope it, so "who can see cross-tenant activity" is a product question surfaced, not answered, by this install.
• Roadmap sequencing for the "record history" workflow. The highest-value first use case is not "browse all activity" — it's subject-scoped history (a support engineer opening an invoice dispute, filtering by subject, seeing status: pending → paid by user 412 at a timestamp). Ship that flow first; if it doesn't come up in week one, neither will the rest. A detail-page history panel inside the existing Nova resource is often more valuable day-to-day than the global browse screen.

When to Consider This Package

Adopt when all of the following hold:

• You already run Laravel Nova and are on a supported Nova × Spatie combination (pin both versions explicitly — zero dependents means you are the first integration test for any pairing).
• You have, or will immediately stand up, spatie/laravel-activitylog as the logging substrate. This package is a viewer. An empty panel is a missing-instrumentation problem nine times out of ten, not a broken tool.
• The need is internal, read-only, low-stakes visibility for support, ops, or engineering — with an owner willing to re-verify after each Nova major upgrade (thin Vue wrappers go stale silently between majors).
• You accept that this is a small screen over an append-only table, and you are prepared to do the surrounding work: morph map decided on day one, indexes on activity_log sized for millions of rows, pruning scheduled at install time, and canSee() gated by a policy rather than left open.

Look elsewhere — or scope a separate feature — when:

• A customer contract or regulator needs audit trails: immutability, export, legal hold, SLA. This panel offers none of that, and letting it become your compliance story is a scope trap.
• You need tamper-evident or write-once storage; activity_log is an ordinary table.
• Your bulk operations run through the query builder (DB::table()->update(), Model::query()->update()), creating invisible audit gaps you can't close without routing writes through models or logging manually.
• You want alerting, anomaly detection, or dashboards — that's a different consumer of the same table, built separately.
• You're not on Nova, or you're on a Nova version this package doesn't declare support for. The tool class plus Vue component is small enough to vendor, but that's a build decision, not an adoption decision.

How to Pitch It (Stakeholders)

One line: A free, MIT-licensed Nova screen that shows administrators who changed what, to which record, and when — built on the activity-logging library we'd need anyway.

For executives: It converts an unanswerable support question ("why did this invoice change?") into a two-click lookup inside the admin panel we already run. It costs a composer install and an afternoon, not a sprint. Its real value as a first step is evidence: if support and security don't use it in the first few weeks, we've learned that audit visibility is not worth funding — cheaply and early. It is explicitly not our compliance answer; durability, retention, and access policy remain ours to define.

For engineering: The durable asset here is the Spatie logging layer, our log-naming convention, our causer resolution, and our indexes — not this UI. The package is a thin, unpinned-risk wrapper over that substrate, so plan to fork it (~one tool class plus a Vue component) and own it internally rather than treat it as a dependency. Two non-negotiables before rollout: decide the morph map on day one (retrofitting means a data migration), and verify authorization by hand with a low-privilege Nova account — the tool's gate is likely all-or-nothing, so cross-tenant visibility needs a policy or a scoped query. Instrument models first, prove rows land in activity_log, then install the viewer. Schedule pruning alongside the migration.