Notifications
Role-targeted, tenant-isolated alerts delivered inside the admin panel.
Overview
InnConnect’s notification system delivers actionable alerts to the right people at the right time. Notifications surface inside the admin panel — no email configuration or external service required.
Three design principles drive the system:
- Role-targeted delivery — each notification is routed to users based on their role, permissions, or identity. Agents see escalation alerts; compliance officers see deadline reminders. Nobody sees noise that is not relevant to their work.
- Per-tenant isolation — every tenant has its own notifications table in its dedicated PostgreSQL database. Notifications created for one tenant are physically separated from all others and can never leak across tenant boundaries.
- Lightweight polling — the bell icon refreshes every 60 seconds using a minimal count-only API call. Full notification data is fetched on demand, keeping background network usage negligible.
In-app delivery
Notifications appear in the header bell icon. No SMTP setup, no third-party integrations — alerts are available the moment you log in.
Role-based targeting
Target by user, role, permission, or broadcast to all. Each method creates individual notification records for precise read-state tracking.
60-second auto-refresh
The unread badge updates automatically. No page reload needed. Backgrounded tabs are throttled by the browser to conserve resources.
Bell Icon
The notification bell sits in the top-right corner of the admin panel header. It provides at-a-glance awareness of pending notifications without leaving the current page.
Screenshot: Notification bell with unread badge and dropdown
| Element | Behaviour |
|---|---|
| Unread badge | A red counter on the bell icon shows the number of unread notifications. Disappears when all are marked as read. |
| Dropdown | Clicking the bell opens a dropdown showing the 5 most recent notifications with type icon, message text, and relative timestamp (e.g. "3 minutes ago"). |
| Mark all read | One-click action in the dropdown header. Marks all unread notifications as read and clears the badge immediately. |
| View all | Link in the dropdown footer. Opens the full Notification Center page. |
Notification Types
Each notification carries a type that determines its icon, severity badge, and default recipient list. The table below lists all supported types.
| Type | Severity | Description | Default recipients |
|---|---|---|---|
user_invited |
Info | A new team member has been invited to the platform. | Users with manage-users permission |
user_deactivated |
Warning | A team member’s account has been deactivated. | Users with manage-users permission |
user_role_changed |
Info | A user’s role or permissions have been changed. | The affected user |
system_alert |
Alert | System-level warning (e.g. low credit balance, failed integration health check). | Tenant admins |
deadline_reminder |
Warning | A compliance task or document deadline is approaching. | Compliance officers + tenant admins |
approval_required |
Action | Content (KB article, compliance document) is awaiting review and approval. | KB managers + tenant admins |
Notification Center
The full Notification Center is accessible from the bell dropdown ("View all") or from Notifications in the sidebar. It provides a paginated list of all notifications for the current user, with filtering and bulk actions.
Screenshot: Notification Center with filter tabs and action buttons
Filters
| Filter | Shows |
|---|---|
| All | Every notification, both read and unread. |
| Unread | Only notifications that have not been acknowledged. |
Actions
- Mark as read — acknowledge a single notification. It remains in the list but no longer contributes to the unread count.
- Mark all as read — clear all unread notifications at once.
- View related item — notifications linked to a resource (escalation, KB article, user) include a direct link. Clicking it navigates to the relevant page.
- Delete — permanently remove a notification from the list. This action cannot be undone.
Targeting Methods
When a notification is created, the NotificationService evaluates which users in the tenant should receive it and creates an individual notification record for each recipient. This ensures per-user read state, per-user deletion, and accurate unread counts.
| Method | How it works | Example |
|---|---|---|
| Single user | Targets one specific user by ID. Used when the notification is relevant to exactly one person. | user_role_changed sent to the user whose role was modified. |
| Role-based | Targets all active users who hold a specific role. The service queries the tenant’s user table for matching roles. | escalation_created sent to all users with the agent role. |
| Permission-based | Targets all active users who hold a specific permission, regardless of which role grants it. More flexible than role-based targeting when a permission spans multiple roles. | user_invited sent to everyone with manage-users permission. |
| Broadcast | Targets all active users in the tenant. Creates one notification record per user. | system_alert broadcast to the entire team. |
Tenant Broadcast
Tenant admins can send a broadcast notification to all active users in the tenant from Notifications → Send Broadcast. Broadcasts are useful for announcing maintenance windows, policy changes, or urgent operational updates.
When creating a broadcast, you specify:
- Message text — plain text, maximum 500 characters.
- Severity — info, warning, or alert (determines the badge colour).
- Link (optional) — URL to a related page or external resource.
- Target — all users, or a specific role.
Broadcast notifications appear in every targeted user’s bell icon simultaneously.
Auto-Refresh
The bell icon polls for new notifications every 60 seconds. This happens automatically while the admin panel is open in a browser tab.
| Behaviour | Detail |
|---|---|
| Polling interval | 60 seconds. A lightweight API endpoint returns only the unread count (single integer). |
| Full data fetch | Notification content is fetched only when the user opens the dropdown or visits the Notification Center. Background polling never transfers full notification payloads. |
| Tab throttling | When the browser tab is backgrounded, the browser may throttle the polling interval (typically to once per minute or slower). The count synchronises as soon as the user returns to the tab. |
| Network usage | Each poll request is under 200 bytes. At one request per minute, background polling adds less than 300 bytes/minute of network traffic. |
Tenant Isolation
Notifications are stored in each tenant’s own PostgreSQL database. There is no shared notifications table. This architectural choice ensures that a query for one tenant’s notifications can never accidentally return data belonging to another tenant, even in the event of an application-level bug.