Filament Activity Timeline Laravel Package

Product Decisions This Supports

• Shipping an audit/history feature without building one. If the roadmap includes "who changed what, when" on records — a common enterprise/ops ask — this package converts existing spatie/laravel-activitylog data into a usable UI, turning a multi-sprint build into a plugin install. The buy-vs-build decision tilts toward buy, conditioned on the maturity caveats below.
• Feature scoping for admin panels. The record timeline (embedded on a resource view page) and the filterable activity resource (a global, queryable log) are two distinct user stories. This lets you decide whether to ship history per-record, org-wide, or both, and price/sequence them accordingly.
• Reducing "why did this change?" support load. Enum/date/foreign-key resolution to human labels ("Status: Draft → Published", "Author: Alex Rivera → Sam Okafor") is the difference between a timeline support staff actually read and a raw JSON blob they ignore. This supports decisions to expose the log to non-technical users (support, ops, compliance reviewers) rather than keeping it engineer-only.
• Compliance and accountability positioning. Auditable change history is a recurring requirement in regulated or enterprise sales cycles. This is a low-cost way to check that box for Filament-based products, informing whether it becomes a standard feature or a paid tier.
• Platform/stack commitment. Adopting it signals continued investment in Filament + spatie/laravel-activitylog as the activity layer, which informs adjacent roadmap choices (event coverage, logging model selection, retention).

When to Consider This Package

Consider it when:

• You already run (or plan to run) Filament for the admin/back-office and spatie/laravel-activitylog for logging. This package is glue between two specific dependencies — it is not useful outside that stack.
• The requirement is readable history for humans, not raw event streaming or analytics. Its core value is presentation: casting values back through the subject model so diffs read like the record on screen.
• You need either or both surfaces: an embedded per-record timeline and a global, filterable activity resource — and want them consistent in look and language.
• You want to avoid writing custom diff-resolution logic (enums, dates, belongs-to relationships) yourself. That resolution layer is the genuinely non-trivial part and the strongest reason to adopt rather than build.
• Time-to-market matters and the team accepts a small, young dependency.

Look elsewhere / build in-house when:

• Maturity risk is unacceptable. 7 GitHub stars, 0 dependents, and a low opportunity score mean limited production validation and a thin community. For a business-critical compliance surface, assess maintenance risk: is it one maintainer? Are issues answered? Does it track Filament major versions promptly? Pin the version and be prepared to fork.
• Filament version churn bites. Filament's major releases move fast; plugins lag. Confirm the package supports your exact Filament version before committing roadmap items to it.
• You need audit-grade guarantees, not just readability: tamper-evidence, immutable stores, retention policy, exportable reports, or legal defensibility. This is a reader, not an audit system. Pair with your own retention/immutability controls or buy a dedicated audit product.
• You aren't on Spatie's activitylog, or you need custom event sourcing / high-volume logging. Rewriting the logging layer to fit a UI plugin is the wrong direction.
• You need heavy customization of timeline rendering, permissions per entry, or complex diff semantics — at which point the build may be small enough to own.

How to Pitch It (Stakeholders)

One-liner: A small plugin that turns the raw activity log we already keep into a clear, human-readable timeline inside our admin panel — so support, ops, and customers can see who changed what and when without an engineer translating JSON.

For executives: We already record every change to our records; today that history is technically present but practically unreadable. This package surfaces it as plain language ("Status: Draft → Published", "Author: Alex Rivera → Sam Okafor") in the admin UI. That means faster support resolution, a credible answer to "can you show an audit trail?" in enterprise deals, and a feature we can ship in days rather than building custom history UI. The trade-off is dependency risk: it's an early-stage, single-maintainer package, so we adopt it with a pinned version and a fallback plan to maintain or fork it ourselves if needed. Low cost, contained risk, visible product value.

For engineering: It's a thin Filament integration over spatie/laravel-activitylog, which we should standardize on as the logging layer. The hard part it solves for us is diff resolution — it runs logged values back through the subject model's casts and relationships so enums, dates, and foreign keys render as labels instead of raw IDs and ISO timestamps. We get two surfaces (record timeline + filterable activity resource) for free. Plan: verify Filament version compatibility, pin the dependency, wrap it so our UI doesn't hard-depend on its internals, and keep the option to fork — MIT license, small surface area, should be tractable. Do not treat it as an audit/compliance store; it's a reader over our existing log, and retention/immutability remain our responsibility.