Integrating Laravel Notifications with Filament Is Easy - Here's How
If you're building a Filament admin panel and need real-time, configurable notifications - the kind where users get a bell icon alert and an email - you don't need a third-party package. Laravel's built-in notification system and Filament's database notifications work together seamlessly. The trick is keeping Laravel as the engine and Filament as the display layer.

The Problem
Filament gives you flash notifications out of the box - those green toast messages that confirm an action. But those disappear on page refresh. What about persistent notifications? The ones that stack up in a bell icon, send emails to the right people, and let users control what they receive?

That requires a real notification system. And if you wire it directly into Filament, you'll regret it the moment you need to send notifications from a queued job, a scheduled command, or a webhook handler.

The Architecture
The solution is straightforward: Laravel handles all notification logic, Filament just reads the result.

Laravel's notification system already supports multiple channels - mail, database, SMS, Slack - through a single class. Filament's databaseNotifications() feature reads from Laravel's standard notifications table and renders them in a bell icon. You don't need to bridge anything. They already speak the same language.

The only catch is formatting. Filament's bell icon expects notifications stored in a specific format. Instead of returning a plain array from toDatabase(), you use Filament's notification builder:

php

public function toDatabase(object $notifiable): array

{

    return FilamentNotification::make()

        ->title('New credit request for invoice #' . $this->invoice->id)

        ->body('Requested by ' . $this->requestedBy->name)

        ->icon('heroicon-o-credit-card')

        ->iconColor('danger')

        ->getDatabaseMessage();

}

That's the glue. getDatabaseMessage() returns the array structure Filament knows how to render. Your toMail() method stays pure Laravel. Your via() method stays pure Laravel. Filament only touches the database channel's output format.

Making It Configurable
A notification system worth building lets you control who gets what through which channel. This means a preferences table:

notification_preferences


├── role (nullable)           — subscribe an entire role

├── user_id (nullable)        — subscribe or override for one user

├── notification_type          — which notification

├── channels (JSON)            — ["email", "database"]

└── is_enabled                 — on/off toggle

Role-level preferences act as defaults - "all admins get invoice credit requests via email and bell." User-level preferences override them - "this specific admin only wants the bell, no email." A user-level row with is_enabled = false opts them out entirely.

A service class sits between your application code and Laravel's $user->notify():

php

NotificationService::dispatch(

    type: NotificationType::InvoiceCreditRequested,

    context: [

        'invoice' => $invoice,

        'requested_by' => $requestingUser,

        'credit_type' => 'full',

        'comment' => 'Incorrect amount',

    ],

    excludeUser: $requestingUser,

);

The service resolves subscribers from preferences, maps channels, excludes the triggering user, and dispatches. The calling code doesn't know or care who receives the notification or how.
Enabling the Bell Icon

One line in your panel provider:

php

return $panel

    ->databaseNotifications()

    ->databaseNotificationsPolling('30s');

That's it. Filament polls the notifications table every 30 seconds and renders unread entries in the top-right bell icon. No custom Livewire components, no JavaScript, no polling logic to write.

Adding a New Notification Type
Once the foundation is in place, adding a new notification is mechanical:

1.         Add a case to your NotificationType enum.

2.         Create a Laravel Notification class with toMail() and toDatabase().

3.         Seed a default preference row.

4.         Call NotificationService::dispatch() from wherever the event happens.

The new type automatically appears in the admin preferences UI because the form reads from NotificationType::cases(). No UI changes needed.

The Decoupling Guarantee
This is the part that matters long-term. Every line of notification logic - subscriber resolution, channel routing, preference checks, email templates - lives in Laravel.

Filament contributes exactly two things: the getDatabaseMessage() format in toDatabase(), and the bell icon rendering via databaseNotifications().

If you ever swap Filament for Inertia, Livewire standalone, or something else entirely, you replace the toDatabase() return value with a plain array and build your own notification dropdown. The rest stays untouched.

Build notifications in Laravel. Display them in Filament. Keep the boundary clean.