Recently Laravel Package

Product Decisions This Supports

• Admin UX investment vs. feature work. "Recently viewed" is a small, high-leverage navigation improvement for operators who touch the same handful of records repeatedly (support agents, reviewers, moderators, account managers). The decision this supports is whether to spend engineering time on workflow polish at all — this package turns that from a ~1–2 day build into an afternoon's configuration.
• Build vs. buy. Building this internally means: a tracking table, a migration, a recorder trait on EditRecord/ViewRecord, a topbar render hook, global-search integration, per-user scoping, dedupe/ordering logic, and ongoing maintenance across Filament major versions. The package supplies all of it plus a supported upgrade path (v1 → v2 → v3 across Filament 3/4/5) for the cost of a composer require and a config file. Default recommendation: buy, unless navigation is a differentiated part of your product.
• Scope/roadmap decision: which surfaces get "resume work." The opt-in trait is the key PM lever — you can enable tracking per resource, so you can ship this to the highest-value 5 resources first and measure before rolling out. No global toggle to argue about.
• Placement and prominence decisions. global_search, menu, maxItems, width, icon, label, and renderUsingHook are all config-level product decisions, not code changes. That means a PM can A/B or stage placement (topbar menu vs. global search only) without an engineering cycle.
• Data retention and privacy posture. v3.2's max_stored_items and prune_after_days make retention an explicit product decision rather than an accident. Combined with track_records hiding deleted records, this addresses the two predictable stakeholder objections ("unbounded table growth" and "links to deleted records") with config, not custom work.
• Support-ticket reduction / time-to-task metric. The plausible success metrics are time-to-find-record, repeat-navigation clicks, and support requests of the form "I can't find the thing I was just working on." This package gives you a cheap way to test that hypothesis.

When to Consider This Package

Adopt when most of the following hold:

• You run a Filament panel on v4 or v5 (v3.x of the package covers both; there is also a 1.x line for Filament 3, but it is now legacy).
• Your users repeatedly return to the same records across sessions — service desks, moderation queues, account management, order/claim handling, editorial review.
• You want the capability without owning the code, and you are comfortable with a community package rather than first-party support.
• You can accept a new table plus one migration (required for the v3.2 track_records feature; publish before enabling).
• Your panel already uses, or can adopt, a custom theme — the README explicitly requires adding the package's views to your theme CSS @source path.

Look elsewhere, or build, when:

• You are not on Filament. The package is a Filament plugin end to end; there is no framework-agnostic core worth extracting.
• What you actually need is an audit trail. This tracks views for user convenience, not who-changed-what compliance evidence. Don't let a stakeholder reframe it as auditing.
• You need cross-panel or cross-product state beyond what panel-scoped configuration and the single user_model binding give you.
• Your dependency governance is strict. 43 stars and effectively no public dependents is thin adoption evidence for a formal vendor review; expect to defend it on "MIT, single small surface, trivially removable" rather than on ecosystem traction. Note the bus-factor: one primary maintainer (though an established Filament contributor).
• Your panel has very few resources — with 3–5 screens, a "recently viewed" menu is clutter, not utility.
• You are already running QuickCreatePlugin or OverlookPlugin. Not a blocker, but you must exclude RecentEntryResource from both, and that pairing is an easy thing to forget during rollout.
• You need guaranteed SLAs or roadmap influence. No commercial support tier here.

How to Pitch It (Stakeholders)

For executives (one paragraph). Our admin panel currently offers no way to return to a record you were just working on; users re-navigate from scratch every time. This is a small, well-scoped MIT-licensed Filament plugin that adds a "Recently Viewed" menu and search integration for roughly an afternoon of configuration instead of a multi-day internal build. It requires no changes to existing behaviour, is enabled per-resource so we can pilot it narrowly, includes retention controls so the tracking table can't grow unbounded, and can be removed with a single dependency deletion if it doesn't land. The main risk is maturity — it's a small community package with a single primary maintainer — which we mitigate by piloting in staging and limiting it to the highest-traffic resources.

For engineering (what they're actually signing up for).

• composer require awcodes/recently, php artisan recently:install, register RecentlyPlugin::make() on the panel.
• Add HasRecentHistoryRecorder to the EditRecord/ViewRecord pages of targeted resources — tracking is opt-in and per-page, so blast radius is controllable.
• One migration, only if we want track_records (hides deleted records). Publish and run it before toggling the option.
• Theme work: register the package views in our CSS @source path, per the Filament custom-theme requirement.
• Conflict check: exclude RecentEntryResource from QuickCreatePlugin and OverlookPlugin if present.
• Set max_stored_items and prune_after_days from day one and confirm model:prune is scheduled; set user_model to our App\Models\User.
• Upgrades are low-drama by design — v3.2's new options all default to prior behaviour — but we should assume the Filament 5 → 6 bump lands on this package's timeline, not ours.

Recommendation: approve as a time-boxed pilot on 3–5 high-traffic resources, gated on staging validation and a retention configuration, with a one-sprint check on whether anyone actually uses the menu.