In-App Notifications for Phoenix SaaS

A user uploads a 50-MB CSV for import and you process it in the background. They sit on the import screen, refresh a few times, then give up and go to lunch. By the time they come back, the import has finished, and they had no way to know — except by checking their inbox for a transactional email that has not arrived yet.

This feature installs an in-app notification center so the moment "the import finished" happens, it shows up where the user already is. Notifications are persisted, delivered over PubSub in real time, and visible on a dedicated /notifications page; users do not need to refresh.

Tell users something happened — without leaving the app

Email is fine for things that survive the session. In-app notifications are for the thing that happened five seconds ago that the user is actively waiting for. Having both is the right answer; this feature is the in-app half, and it composes naturally with html_emails for the email half.

What This Feature Adds

• MyApp.Notifications context with create_notification/2 and dismiss / list helpers
• MyApp.Notifications.Notification schema and a generated migration
• MyApp.Notifications.Dispatcher and DeliveryMethod modules so future delivery channels (email, mobile push) can be added without rewriting the context
• An authenticated MyAppWeb.NotificationsLive mounted at /notifications
• Real-time delivery via Phoenix.PubSub so the page updates without a refresh
• A nav link in the app layout pointing at /notifications
• Generated LiveView tests

How It Fits Into Your Phoenix Application

Application code creates notifications through the context. The context persists the row, broadcasts on PubSub, and the LiveView picks up the change:

MyApp.Notifications.create_notification(current_scope, %{
  type: "import_finished",
  title: "Import finished",
  body: "Your CSV import processed 4,820 rows.",
  url: ~p"/imports/#{import.id}"
})

The current_scope argument carries the user (and team, if teams is installed) for proper scoping. The Dispatcher module is where you would route certain notification types to email later — by composing this feature with html_emails, you can decide per-type whether to send an email in addition to the in-app notification.

Installation Notes

• Hard dependencies: authentication and layouts. The feature assumes a current_scope, an authenticated routing pipeline, and an app layout to link from.
• Recommended pairing: html_emails, listed in the manifest as recommended_features, for when you want email delivery alongside in-app.
• Run mix ecto.migrate after install to create the notifications table.
• Open /notifications as a signed-in user to verify the empty state, then create a notification from IEx to confirm real-time delivery.

Build This With Live SaaS Kit

Install saas_kit, then mix saaskit.feature.install notifications to give your users a place to see what happened while they were away from the page.