> For the complete documentation index, see [llms.txt](https://docs.sealsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealsecurity.io/using-platform/notification-center.md).
# The Notification Center
Seal delivers notifications through two channels. The in-app **Notification Center** lives inside the Seal UI; **email notifications** deliver to your inbox. Email is a subset of the most important in-app events: anything that reaches you by email is also a notification in-app, but most in-app notifications do not also email you.
## The in-app Notification Center
The Notification Center is opened from the bell icon at the top of the Seal UI. Clicking the bell opens a popover with your most recent notifications, newest first. Each entry shows the event and the time it was delivered. Read and unread states are tracked per notification.
The bell icon's popover lists your most recent notifications.
Clicking **See all** from the popover opens the full Notifications page. The full page lists every notification delivered to your user, in reverse chronological order, with the same read/unread state shown in the popover.
On the full page, each row is one notification with row-level actions: mark as read or unread, archive, jump to whatever Seal page the notification refers to (a Vulnerable packages tab row, a Sealing rule, a project, depending on what the notification is about). Archived notifications move out of the active list into the archive view; from the archive, you can unarchive a notification back into the active list. The archive is the place to look when you remember an alert from last week and want to find it again.
The full Notifications page, with per-row actions and the archive view.
A broad and growing set of events fires in-app. Examples that ship today:
* A new vulnerability is discovered in a package your tenant uses, and the package is already on a sealed version.
* A new vulnerability is discovered in a package your tenant uses that is not yet sealed.
* A new sealed version is released for a package you are already using.
* A Seal Project's state changes (deleted, archived, restored) — delivered to admins of the tenant.
* A source-control integration event affecting your tenant — for example, the Seal GitHub App failing to open a pull request it tried to create.
The set expands as the platform adds new event types.
Notifications are delivered per user and scoped to the tenant. You see what is relevant to your role and the projects you have access to; other users in the same tenant see their own list.
## Personal email notifications
Email notifications are configured per user under **Settings > User > Notifications**. A switch on that page controls whether your user receives email from Seal.
Email is a curated subset of the in-app notifications — only the events Seal thinks warrant pulling you out of whatever you're doing get sent by email. Today, that subset is one event: **a new sealed version is released for a package you are already using.** This is the case where Seal has fixed vulnerabilities (typically disclosed after your current sealed version was released) and you should consider rolling forward; the email pulls your attention to the fix as soon as it ships.
Email is opt-in. Until a user enables the switch on their Settings page, no email goes out for that user. Each user controls their own preference.
## In-app vs email
The two channels handle different operational needs:
* **In-app** is the read channel for everything that happens inside Seal. The bell icon's unread count is the signal; the popover and the full Notifications page are where you read.
* **Email** is the push channel for the small set of events you want to reach you outside the Seal UI. Configure it under Settings when you want Seal to nudge you in your inbox.
A user who lives in Slack or in their team's dashboard most of the day usually relies on email to draw them back into the platform when something specific lands. A user who works in the Seal UI day-to-day usually relies on the bell icon and leaves email off.
## Related
* [The Seal UI tour](/using-platform/seal-ui-tour.md): the chapter that orients you to the bell icon and the rest of the top-level navigation.
* [Settings > User > Notifications](/getting-started/users-and-sso.md): the page where each user configures their email preference.