Notifications and the attention list

The two lists behind the bell

The bell in the app's top bar opens two lists, and we keep them separate because they do different jobs.

The notifications feed is a record of events, such as a scan finishing, a banner going live or someone joining the team. Each entry was true when it was written and stays true, which is why you can mark it read but can't delete it.

The attention list doesn't record anything. It's a live reading of your account, recomputed every time you look, and it shows conditions that hold right now and need a person to act. It has no read state, because reading an item doesn't resolve it. An item leaves the list as soon as the thing it names is fixed.

The bell shows the attention list in full and the feed's most recent entries. The account's notifications page shows both in full.

What lands in the feed?

Feed entries come from things that happen 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 being verified, which happens 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).

Everyone on the account sees the same events, because the feed is account-wide. It isn't an archive, and entries are cleared out after roughly ninety days. Permanent records are kept in the consent log and the audit trail.

Read status is per person

Read state is per person, so the unread count is about you, and a teammate reading the same feed doesn't change it. Opening an entry marks it read, and you can also mark entries read one at a time or all at once. That's the only thing you can do to a notification. There's no dismiss and no delete, because a record of something that happened stays true after you've seen it.

What the attention list checks

The list is derived from current state, so it's made up of conditions and has no events in it. As of this writing, it checks for:

• Billing trouble: a trial about to end or already ended, a checkout that never finished, or a payment past due. These show to owners and admins, so a viewer won't see them. Only an owner can fix them, and an admin who follows the alert is told who the owner is.
• A failed last scan on a site.
• Cookies set before consent at a site's last scan. This 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. That second case usually means the snippet was removed in a redesign and consent recording 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, such as the generator noting cookies it had to leave out. The standing draft disclaimer on every generated document doesn't count. Only caveats you can act on do.

Each item has one of three severities: something the product promises is broken or paused right now, something is heading that way, or work is waiting but blocks nothing yet. The list doesn't make you compliant. It's UserGuard's reading of your account's state, and what your obligations require is a question for you and your counsel.

Can you dismiss an attention item?

Waiting-work items, plus advisory items such as high-severity AI flags. Other items in the first two severities can't be dismissed, because they describe gaps, and hiding a gap wouldn't close it. The only way to clear them is to fix what they name.

You can dismiss waiting-work items because some of that work gets left as it is on purpose. A dismissal applies only to you, and it's tied to what the item said when you dismissed it. As soon as the facts change, the item returns, for example when two caveats become three or the same condition comes back months later. So a dismissal acknowledges one specific state of affairs and leaves the topic open.

How the two lists stay in sync

The attention list shows only what's true now, so once a snippet comes back, nothing in the list says it was ever gone. That history is in the feed. When a condition starts holding, the feed gets one record of it within about ten minutes, and the record isn't repeated on later checks while the condition keeps holding. When the condition clears, the record stays in your history, marked resolved. If the condition comes back later, it's recorded again.

Not every condition gets a feed record. Routine standing work (cookies awaiting categorization or approval, document caveats and AI flags) appears only in the attention list, because a queue with work in it isn't an event.

You'll notice one consequence on the notifications page. Each condition appears only once per screen. While an item is live in the attention list, the feed record of the same condition is hidden, and it reappears in the history once the condition clears.