Activity Log Laravel Package

Product Decisions This Supports

• "History" / "Activity" tab as table stakes in admin tooling. Most back-office products eventually need a per-record timeline (customer, order, ticket, contract). This package turns that from a per-model custom build into a config-and-ship task, directly shrinking roadmap estimates for any admin-surface epic.
• Build vs. buy for the presentation layer. The decision it forces is a useful one: buy (adopt) the timeline UI, build your own event emission. It does not solve recording, retention, or compliance — so it should be scoped as a UI accelerator, not an audit system.
• CRM / ops-parity roadmap. If competitors show a unified "what happened here" feed and we don't, this is the cheapest path to closing that gap, especially where events span multiple related models (e.g., a contact plus their deals plus their emails in one stream).
• Support-enablement and internal trust features. A visible activity trail measurably reduces "why did this change?" tickets for support and CS. That's a product decision about internal efficiency, not user-facing differentiation.
• Where not to spend differentiation budget. With a low opportunity score (~2.2) and 17 stars, this is not a strategic bet — it's commodity plumbing. The decision it supports is to stop deliberating on timeline UI and reallocate design/engineering attention to features that actually differentiate.

When to Consider This Package

Consider it when:

• The stack is Laravel + Filament and the timeline is internal/admin-facing. This package is a Filament plugin; adopting it off-Filament means rewriting the view layer anyway.
• The consumer is operators, support, or CS — people who need a chronological feed, not a queryable analytics surface.
• Activity events are already recorded or trivially recordable via an existing logger (e.g., spatie/laravel-activitylog). The plugin renders; something else must write.
• You need a cross-model, unified feed rather than a single per-model table — that's the stated differentiator and the main reason not to hand-roll.
• You are time-constrained (MVP, internal launch, a client deliverable) and a vendor-fork is acceptable. At 17 stars and a single visible maintainer, budget an afternoon to read the source and confirm you can own it if abandoned.
• You have validated Filament and PHP version compatibility against your app before committing to a sprint plan.

Look elsewhere when:

• You need compliance-grade audit: immutability/tamper evidence, WORM storage, legal retention policies, export for SOC 2 / HIPAA / GDPR subject-access requests, or field-level redaction by role. This package does not claim that, and treating it as such is a real risk.
• You need analytics or aggregation — funnels, time-in-stage, cohort behaviour. That's a warehouse/event-streaming problem, not a timeline widget.
• Volume is high-throughput (millions of events/day) or events must drive downstream automation; you want an event-sourcing or queue-backed pipeline, with the UI as a thin read model.
• The timeline is customer-facing. Branding, latency, pagination, localization, and information-hiding requirements usually mean you should own that component outright.
• You require strict multi-tenant partitioning or per-plan feature gating on what activity is visible — verify (and likely extend) rather than assume.
• Your organization has a policy against low-adoption single-maintainer dependencies in production admin paths and won't sanction a fork.

How to Pitch It (Stakeholders)

For executives (one line): A small, MIT-licensed add-on that gives every record in our admin a ready-made history feed, so we stop rebuilding the same timeline screen per feature — low cost, low risk, and fully reversible.

For executives (the honest framing): This is a velocity purchase, not a capability purchase. It saves days per admin feature and improves support efficiency. It does not satisfy audit or compliance obligations, and it is a small open-source project — so we isolate it behind our own internal wrapper and keep the option to replace it in a day. Expect low cost, modest and measurable time savings, and no lock-in.

For engineering: It's a Filament component, so integration is a plugin registration plus a relation-manager/action on the models we choose — no new infrastructure. The real work, and the part worth doing regardless of this package, is emitting consistent activity events from domain actions; that's good hygiene and pays off for debugging and support. Recommended guardrails: pin the version, read the source before merge (it's small), wrap it in our own ActivityTimeline component so call sites don't depend on the vendor's API, and confirm Filament/PHP version support and test coverage before we commit it to a release. If it's abandoned, we fork — the blast radius is one UI component, not a subsystem.

The ask: Approve a timeboxed spike (1–2 days) to integrate against one representative model. Success criteria: a working timeline for two different models, event emission standardized for one domain area, and a documented fork/replace path. If the spike fails those, we build a minimal in-house view — the recording layer we'd write either way.