Skip to main content

Notifications

Notifications are how Lumio nudges you about things that need your attention: pending team invites, connections that went south, system-level announcements, and similar account events. They live in a dropdown under the bell icon in the dashboard's top bar — no inbox, no separate page, just a quick glance and an inline action.

Where to find it

The bell icon sits in the top-right corner of the dashboard, next to your account switcher and avatar. If you have unread notifications, a small badge shows the count (1, 2, … up to 99+). Click the bell to open the dropdown.

If there's no badge and the dropdown says No notifications yet., there's genuinely nothing — the dropdown doesn't hide anything you haven't dismissed.

Quick start

  1. Click the bell icon in the top-right.
  2. Unread items are highlighted with a subtle accent background.
  3. Click the check icon on any item to mark it as read.
  4. Click Mark all as read in the dropdown header to clear the badge.
  5. If a notification has buttons (e.g. Accept / Decline for an invite), click one to run the action inline — no separate page needed.

That's the whole UI. There is no notification settings page, no preferences panel, no opt-out toggles — Lumio only sends notifications for things that legitimately require your attention, so there isn't anything to configure.

The bell dropdown in depth

When you open it, you see:

  • A header with the title Notifications and, if there's anything unread, a Mark all as read shortcut.
  • The most recent 10 notifications, ordered newest first.
  • Each row shows: title (bold), optional message (lighter text), timestamp (localized to your browser), an inline check button to mark it read, and — if the notification is actionable — one or more action buttons.
  • A scrollable list: scroll inside the dropdown to see the full ten.

The dropdown closes when you click outside it or hit Esc via the button.

Polling and freshness

The bell polls /api/notifications?limit=10 every 30 seconds in the background, even when the dropdown is closed. That means:

  • A new notification can take up to 30 seconds to appear after the backend creates it.
  • The badge stays roughly in sync without any manual refresh.
  • Polling runs silently; if a request fails (network blip, API restart), the UI just keeps the last-known state and tries again 30 seconds later.

If you need a fresh view right now, close and reopen the dropdown — reopening doesn't trigger a fetch by itself, but the next polling cycle is at most 30 seconds away.

Notification types

Notifications today include:

  • Pending invites — Someone invited you to join their account. These carry Accept and Decline action buttons. Accepting adds you as a member; declining leaves the invite untouched but removes the notification from your list.
  • Connection / OAuth issues — A platform token refresh failed and requires you to reconnect. The notification links you back to the Connections page.
  • System announcements — Maintenance windows, feature launches, breaking-change heads-ups from the Lumio team.
  • Team activity — Events like a role being changed on your account, an invite you sent being accepted, etc.

Each notification carries a machine-readable type string on the backend, but you interact with it through its human-readable title and message — the type is only relevant when triaging bugs with support.

Actions

Actionable notifications have one or more buttons below the message. The most common example is invite:

  • Accept invite — adds you as a member of the inviting account. The notification is marked as acted (won't show action buttons again).
  • Decline invite — dismisses the invite.

Clicking an action disables both buttons while the server processes the request, then updates the notification to its final state. If the action fails (e.g. the invite expired between the time you saw it and clicked), the button re-enables — try refreshing and check Dashboard > Members > Invites instead.

Once a notification has been acted on, the buttons disappear. The notification stays in your list (now read and acted) so you have a trail of what happened.

Permissions

Notifications are always scoped to you as a user, not to an account. That means:

  • Switching accounts does not change what you see in the bell — your pending invites, system announcements, etc. are yours.
  • No RBAC permission is required to view or interact with your own notifications.
  • Notifications that trigger an action (like accepting an invite) follow the permissions of that action — e.g. Accept invite uses the same backend path as POST /api/members/accept-invite.
CapabilityRequired Permission
See your own notifications(none — tied to your user)
Mark one as read(none — your own)
Mark all as read(none — your own)
Execute an action buttonPermission of the underlying action (e.g. invite acceptance has no permission gate — it's a user-level decision)

Tips & best practices

  • Clear invites promptly. Accept or decline them rather than letting them pile up. Declined/accepted ones disappear from the action state and no longer prompt you.
  • Fix connection notifications immediately. A "token refresh failed" notification means chat, events, or moderation on that platform isn't working. Click through to Connections and reconnect.
  • Don't rely on notifications for real-time events. Chat messages, follows, subs, etc. flow through the WebSocket event pipeline, not the notification bell. Use Dashboard > Events or the overlay Event List for stream-time activity.
  • Mark all as read after triage. It keeps the badge honest. If you leave read notifications around, the badge won't come back — but fresh unreads will still show up.

Troubleshooting

Badge shows a number but the dropdown is empty. The dropdown shows the most recent 10. If you have more than 10 unread, older ones aren't visible here — use Mark all as read to reset, or triage the visible ones first.

I accepted an invite but nothing happened. Check Dashboard > Members for your new membership. Then switch to that account via the account switcher. The bell notification stays (acted state) as a receipt.

Invite action buttons are disabled and stuck. The request is in flight. Wait a few seconds; if they stay disabled, the action likely failed silently — refresh the page and the updated state will load via the next poll.

The bell doesn't appear at all. You're probably looking at a page outside the authenticated dashboard (e.g. /overlay/..., /login). The bell is part of the dashboard shell and only renders when you're signed in.

I want to disable notifications. There isn't a preferences UI — Lumio only sends notifications for things that need your attention. If a type is genuinely noisy for your workflow, open a feature request.

New notification didn't appear for ~30 seconds. Expected. Polling is on a 30-second cadence. Reload the page to fetch immediately.

  • Members — sending and managing invites, which is where most of the invite notifications originate.
  • Connections — reconnecting a platform after a token refresh failure.
  • Roles and Permissions — understanding the actions behind notification buttons.