Skip to main content
Scanova has two separate notification surfaces, verified live against the running app: the bell icon in the top bar (present on every dashboard page), and a dedicated /notifications page. They are not the same system — see Two notification systems below before you go looking for one in the other. This page documents /notifications, the module in scope here — a simple All / Unread inbox for account-level events like team invitations, quota warnings, and lead or form-response alerts.
This is not where you control which emails Scanova sends you. For that, see Email preferences — a separate, six-category toggle list at /account/email-preferences. This page is about in-app messages you read in the dashboard, not your inbox.

​
The notifications page

Open /notifications directly (there’s no sidebar link to it — see the discrepancy note below). The layout is a two-pane inbox:
  • Left pane — a scrollable list of notifications, each showing a title, a one-line body preview, and a relative timestamp. Unread items carry a filled dot and bold title; read items don’t.
  • Right pane — a detail view for whichever notification you’ve selected, showing the full title, an absolute timestamp, and the full body text. If the notification carries a deep link, an Open button appears in the detail header.
Notifications page showing All and Unread tabs, an empty notification list reading 'No notifications — You're all caught up!', and an empty detail pane reading 'Select a notification — Choose one from the list to read it'

The Notifications page, verified live on a test account with no notifications yet

At the top of the list, two tabs filter what’s shown: A Mark all read button appears next to the tab row whenever you have at least one unread notification, and clears them all in a single click. Selecting an unread notification from the list marks it read immediately (no separate confirmation) and updates its dot/bold styling in place.

​
Notification types

The account used to verify this page had zero notifications, so no live example could be captured. Based on the backend’s registered notification workflows (qcg-backend/src/notification/workflows.py), four event types are wired to fire a notification:
The backend code itself flags these four as “proposed, not confirmed” against the underlying notification-delivery service’s dashboard at the time they were wired up — treat this list as the intended set of triggers, not a guarantee that every one of them is live in production today.

​
Two notification systems (a real discrepancy)

Live verification found that the bell icon in the top bar — the notification entry point every user actually sees, on every dashboard page — is a different, separate widget from the /notifications page described above:
A popover opened from the top bar bell icon, showing a dropdown labeled Inbox, several loading-skeleton notification rows, and a small 'Inbox by Novu' attribution at the bottom

Clicking the top bar bell icon opens a separate, third-party-branded inbox widget, not the /notifications page

  • The bell renders a third-party embedded inbox widget (attributed “Inbox by Novu” in its own footer) with its own read/unread state, its own popover UI, and its own real-time delivery — this is what the four event types in the table above actually feed.
  • The /notifications page documented above is a separate, custom-built page hitting its own backend endpoint, with its own data shape. It is not linked from the sidebar, the top bar, or anywhere else in the app that this verification pass could find — the only way to reach it is by typing the URL directly.
If you’re looking for your notifications day-to-day, use the bell icon in the top bar, not /notifications. This page is documented as-is because it’s a real, reachable route, but it should not be treated as the primary notification surface.
  • Email preferences — controlling which emails Scanova sends you, a separate system from both notification surfaces on this page.