Filament Alert Box Laravel Package

Product Decisions This Supports

• Multi-audience alerting without engineering work. Alerts can now be targeted per Filament panel (e.g. admin vs members), which lets ops, support, or marketing publish different messaging to internal staff and to customers/end users from a single admin surface — no deploy required.
• Roadmap: opening new panels/portals. Per-panel scoping removes the previous blocker where any new panel would inherit and be able to edit every other panel's alerts. This directly supports decisions to launch additional panels (partner portal, member area, regional back offices) without accumulating cross-contamination risk.
• Build vs buy. The package supplies the alert CRUD UI ("Manage alerts"), render-hook plumbing, and now panel isolation. Buying this replaces a small-but-nontrivial internal build (settings storage, hook registration, admin page) with a config-level dependency.
• Public-facing announcements. Custom hooks remain global by design, so banner content can be authored in the panel UI and rendered from Blade views outside any panel (marketing site, status page) — useful for outage notices and campaign messaging.
• Upgrade scheduling as a product decision. 2.0.0 is a breaking storage change. The decision is not whether the feature is desirable but when to take the migration — the command supports --dry-run for a rehearsal and --all --no-interaction for pipeline automation, so it can be slotted into a normal release window.
• Demo and QA velocity. The seeder now populates demo alerts into every registered panel using the new format, which shortens sales-demo and QA-fixture setup for multi-panel environments.

When to Consider This Package

Adopt when:

• You already run Filament and have two or more panels, or have concrete plans to add one within the next couple of release cycles.
• Non-engineers need to publish and edit alert banners per audience, and you want that behind a UI rather than config edits and deploys.
• You need banners on public Blade pages in addition to panel UIs — that is exactly what the global custom hooks cover.
• You can absorb a breaking change now, in exchange for not rebuilding alert storage later once panels multiply.

Look elsewhere, or defer, when:

• You run a single panel and don't need per-audience targeting — Filament notifications or a simple settings field are cheaper and carry no upgrade cost.
• You need targeting by user, role, or segment, scheduling, expiry automation, read receipts, or impression analytics. This is a per-panel content store, not a campaign or in-app messaging platform; those requirements mean a different tool.
• You have many panels (dozens or more). The --all migration duplicates the existing alert list into every registered panel by design, so a large panel count converts the upgrade into a non-trivial per-panel cleanup task. Confirm the volume before committing.
• You cannot tolerate a storage-format breaking change in this cycle. Staying on 1.x is viable but locks in the shared-alert model and the cross-panel edit problem.
• Alerts are treated as compliance-critical content where silent duplication or stale copies carry real risk — the "nothing is lost" guarantee is reassuring, but duplicated alerts land in panels you may not expect until someone prunes them.

How to Pitch It (Stakeholders)

For executives. This is a small, targeted dependency that lets non-technical teams control the alert banners shown to different audiences — internal staff and customers — without engineering involvement. Release 2.0 makes it safe to run alongside multiple portals: previously an alert created for one audience was visible and editable from every other admin area, which is a governance problem as we add panels. The upgrade is a planned maintenance item, not a re-architecture, and there is no data-loss path.

For engineering. 2.0.0 changes alert storage from one shared list to a per-panel map. The migration is a first-class artisan command: run php artisan filament-alert-box:migrate-alerts --dry-run to preview, then --all --no-interaction in CI/CD or the interactive flow locally. If the command is skipped, the plugin auto-migrates the first time any panel's Manage alerts page is saved — safe, but non-deterministic, so prefer the explicit path. Two behavioral changes need verification: custom hooks are now registered once globally from the service provider rather than per panel during boot(), so re-check any public-facing Blade banner; and AlertBoxSeeder now writes the per-panel format across all registered panels, so update fixtures and demo seeds. New AlertBox::isCustomHook() and isLegacyAlertsFormat() helpers are available for tests and any custom logic.

Risk and effort framing. No data is deleted at any point; the migration duplicates existing alerts into the panels you select. That duplication is deliberate and requires a short cleanup pass — open each panel's Manage alerts page and remove what doesn't belong. Effort is small for typical installations: bump the dependency, rehearse with --dry-run, run the migration in the release window, verify the public banner and the seeder, then prune. The main thing to avoid is running --all on an installation with many panels or a large alert list without a plan for the cleanup, since every panel will receive a copy.