Notifications and the attention list

Two lists behind one bell

The bell in the app's top bar opens onto two lists, and keeping them apart is the point.

The notifications feed is a record of events: a scan finished, a banner went live, someone joined the team. Each entry was true when it was written and stays true, which is why you can mark it read but never delete it.

The attention list is not a record of anything. It is a live reading of your account, recomputed every time you look, showing conditions that hold right now and need a person to act. It has no read state, because reading is not the action it is asking for. An item leaves the list the moment the thing it names is fixed.

Both live behind the bell — the attention list in full, the feed's most recent entries — and both in full on the account's notifications page.

What lands in the feed

Feed entries come from things actually happening in the account:

• A scan finishing, noting whether any cookies appeared or disappeared, and a scan failing, with the error that stopped it.
• A publish going live — the banner, the accessibility widget, or the Do Not Sell link — with its new version number and who published it.
• The snippet verifying itself: the first time the installed script fetches its configuration from a real page on your site.
• A payment failing, and the subscription recovering afterward.
• Someone accepting an invite and joining the team, with their role.
• A condition from the attention list starting to hold — more on that below.

The feed is account-wide: everyone on the account sees the same events. It is also a feed, not an archive — entries are cleared out after roughly ninety days. The consent log and the audit trail are where permanent records live.

Read is yours alone

Read state is per person. The unread count is about you — a teammate reading the same feed changes nothing for you. Opening an entry marks it read, and you can also mark entries read one at a time or all at once. That is the only thing you can do to a notification: there is no dismiss and no delete, because a record of something that happened does not stop being true once you have seen it.

What the attention list watches

Because the list is derived from current state, the honest description is a list of conditions, not events. As of this writing it watches for:

• Billing trouble — a trial about to end or already ended, a checkout that never finished, a payment past due. These show only to people whose role can fix them; a viewer gains nothing from being nagged about a door they cannot open.
• A failed last scan on a site.
• Cookies set before consent at a site's last scan. Clears when a later scan finds none.
• Snippet problems — a site with a tool turned on whose snippet has never been detected after the first day, or a snippet that verified once but has fetched nothing for over a week, which usually means it was removed in a redesign and consent recording quietly stopped with it.
• Cookies needing a category, which block approval and the cookie policy, and cookies awaiting approval.
• High-severity flags raised by the AI review of the last scan.
• Published documents carrying caveats — the generator noting, say, cookies it had to leave out. The standing draft disclaimer every generated document carries does not count; only caveats you can act on do.

Each item carries a severity: something the product promises is broken or paused right now, something heading that way, or work that is waiting but blocks nothing yet. And the list does not make you compliant — it is UserGuard's reading of your account's state, and what your obligations actually require is a question for you and your counsel.

Fix it, or hide it until it changes

Items in the first two severities cannot be dismissed. They describe gaps, and a gap that could be swiped away would still be a gap. The only way to clear them is to fix what they name.

Waiting-work items can be dismissed, because some of that work is deliberately left as-is. A dismissal is personal to you, and it is tied to what the item said when you dismissed it. The moment the facts change — two caveats become three, or the same condition comes back months later — the item returns. You are acknowledging a specific state of affairs, not silencing a topic.

How the two lists stay in sync

The attention list is honest precisely because it forgets: once a snippet comes back, nothing in the list says it was ever gone. The feed is the memory. When a condition starts holding, the feed gets one record of it within about ten minutes. While the condition keeps holding, it is said once, not repeated on every check. When it clears, the record stays in your history, marked resolved — and if the condition later recurs, that is news, and it is recorded again.

Not every condition earns a feed record. Routine standing work — cookies awaiting categorization or approval, document caveats, AI flags — lives in the attention list only, because a queue having work in it is not an event.

One consequence you will notice on the notifications page: a condition is stated once per screen. While an item is live in the attention list, the feed record of the same condition is hidden; it reappears in the history once the condition clears.