Filament Notifications Tabs Laravel Package

Product Decisions This Supports

• Notification UX polish vs. custom build. Decides whether to ship a low-cost, off-the-shelf improvement to the admin notification center this sprint instead of scheduling a bespoke notification UI. The package covers two specific, recurring requests — "show me only unread" and "let me clear/mark things without opening each one" — which are usually the top usability complaints about Filament's default modal.
• Triage workflow design. The Unread/All tabs plus per-item read/unread/delete actions define a clear default behavior: land on unread, act in place, clear the badge. This lets you commit to a workflow ("zero-inbox within the admin panel") that you can measure — time-to-clear, unread backlog per user, support tickets mentioning notifications.
• Build vs. buy for a thin UI layer. The scope is small (a Blade view + service provider overriding Filament's notifications modal). "Buy" costs ~a few hours including Tailwind @source wiring and a theme rebuild; "build" costs a few days of Filament internals work plus ongoing maintenance across Filament majors. MIT license means forking or vendoring the views is a legitimate fallback if the package stalls.
• Roadmap sequencing. Use it as a stopgap to close out usability feedback while the real notifications strategy (channels, preferences, digests, grouping, real-time via Echo) is still in discovery. It should not be positioned as a substitute for that strategy.
• Scope fit. Only relevant to products with a Filament v5 admin surface — internal ops tools, back-office consoles, support dashboards. For customer-facing notification experiences (email, in-app for end users), this package contributes nothing.
• Risk budget for dependencies. A concrete input to your dependency policy: is a 0.0.x, single-maintainer, ~10-star package acceptable for a non-critical UI surface? Here the blast radius is contained (UI only, no schema, no data path).

When to Consider This Package

Adopt when:

• You are on Filament v5 panels with databaseNotifications() enabled and users receive more than a handful of notifications.
• You have concrete feedback that users can't distinguish read from unread, or that clearing notifications is tedious.
• You want a UI-only change with no migrations, no schema changes, no API surface, and a one-commit rollback.
• You can absorb the setup cost: register the Tailwind @source path in your Filament theme CSS and rebuild assets.
• 0.0.x is acceptable — pin the exact version and read the source (it is small) rather than floating the constraint.
• You are comfortable with a fork/vendor fallback if maintenance stops; the MIT license makes that trivial.

Look elsewhere when:

• You are on Filament v3 or v4 — the README states v5 compatibility, so verify before committing.
• You need notification categories, grouping, digests, per-user channel preferences, or real-time delivery — this is purely a presentation layer over the existing modal.
• Your governance requires vendor SLAs, security review, or demonstrated maintenance. Signals here are weak: 10 stars, 0 dependents, one maintainer, 0.0.x versioning. Treat it as a snippet you happen to install rather than a supported product.
• You have already customized the notifications modal in your panel — overrides will conflict and you'll spend more reconciling than rebuilding.
• Your user base sees only a few notifications ever; the tabs and badge add no value at that volume.
• The Tailwind build step is a real obstacle (locked-down asset pipeline, no theme customization in your setup) — then reimplementing the two views in-house is cleaner.

How to Pitch It (Stakeholders)

For executives: This is a small, reversible UX fix to the admin notification center. It addresses a recurring usability complaint — users can't tell what's unread and can't clear items without opening them — with no database changes, no new infrastructure, and no licensing cost (MIT). Cost is roughly a few hours of setup plus a Tailwind rebuild; the change is contained to one screen and can be reverted in a single commit. The strategic caveat: it is a stopgap, not a notifications strategy. It buys us time to design the real thing (channels, preferences, digests) without leaving users stuck in the meantime, and its main risk — thin maintenance on an early-stage package — is mitigated by the license allowing us to vendor the code ourselves.

For engineering: Two Blade views plus a service provider that overrides Filament's notifications modal to add an Unread tab (with count badge) and All tab, and to swap the default close button for delete and read/unread toggle actions. Requires adding an @source directive pointing at the package's views in the Filament theme CSS and rebuilding assets. Pin to ^0.0.2; no migrations, no schema, no API. Ask: review the package source before merge (it's small), vendor-publish the views if we want to own it outright, and add a checklist item to re-verify on each Filament major upgrade.