Notifications
Every notification type, grouped by area, each deliverable in the bell, by email, or by push, with per-type preferences you control.
Notifications keep you and your team in the loop on what's happening across your spaces: a teammate joins, a customer's chat is escalated to a human, a lead is captured, a post fails to publish. AnyBot groups its notification types by area, and each one can reach you three ways: in the app, by email, or by push.
Three ways a notification reaches you
Every notification type routes through the same three delivery channels:
- In-app (the bell): events show up under the bell in real time and add to an unread count. Most types default to the bell, but it's a per-type toggle like the others; a few types (such as a new inbound message) default to push only and don't add a bell entry.
- Email: reserved by default for the events that matter when you're away from the app: an escalation, a member removed, a billing change, your welcome message. You opt the rest in or out per type.
- Push: a browser web-push notification (it works even when the tab is closed) or, in the mobile app, a native device notification. Push is on by default for time-sensitive, human-in-the-loop events like escalations and new leads.
Sensible defaults ship per type, so you get the high-signal things without configuring anything. From there, preferences are yours to tune.
What you get notified about
Notification types cluster into categories by area. The default reach column shows where each category tends to land before you change anything.
| Category | What triggers it | Typical default reach |
|---|---|---|
| Space & team | A member is added or removed, a space is deleted, an invite arrives | Bell; email on removals, deletions, and invites; push on invites |
| Bots | An agent is created or deleted | Bell |
| Inbox & messages | A conversation starts, gets escalated to a human, or a new message arrives | Bell + push on new conversations and escalations; new messages are push-only by default; email when a chat is escalated |
| Leads | A lead is captured by one of your agents | Bell and push |
| Support | A support ticket is replied to or resolved; a customer ticket is opened or assigned | Bell and push |
| Social | Your brand is mentioned in a post, a comment is assigned to you, or one of your posts fails to publish or can't be confirmed | Bell and push; a failed or unconfirmed post also reaches you by email |
| Knowledge | A knowledge file finishes processing for RAG | Bell |
| Add-ons | An integration is installed or uninstalled | Bell (a received-webhook notification type exists but is off on every channel by default) |
| Billing | Your subscription changes or a token pool is exhausted | Bell; email on plan changes |
| Account | You register, or a referral of yours is used | Bell; email on sign-up; push on referrals |
Escalations are the clearest example of the defaults doing their job: when an agent hands a conversation to a human, that single event fires on all three channels at once, because someone is waiting on a person to reply.
Per-type preferences
You control notifications per type, per channel. In your preferences, grouped by area, you'll see every type with three toggles (bell, email, and push) and you flip exactly the combinations you want. Turn social-mention pushes off but keep failed-post emails on; mute add-on chatter entirely; leave escalations loud. Preferences are per user, so each teammate tunes their own reach without affecting anyone else's.
Changing a preference never changes what happens in the platform. It only changes whether that event reaches you and how. For most types the bell keeps the record even when you've quieted email and push; a few (like new inbound messages) are push-only by default, so turn their bell toggle on if you want them there too.
The bell
The bell in the app is the live in-app feed. It shows an unread count that updates live and lets you open any one to jump straight to the thing it's about: the escalated conversation, the new lead, the processed file. New notifications pop up as they arrive, with an optional soft sound. You can mark a single notification read, mark everything read at once, or dismiss items you're done with. Counts and read-state are per user and update in real time across your open tabs.
For push to work in the browser you allow notifications once; AnyBot registers the subscription and can then reach you even with the tab closed. You can register more than one browser or device and manage them from your notification settings.
Notifications are about awareness, not permissions. You're told about events you already have access to. What each teammate can do is governed separately by roles and permissions, and every underlying change is recorded in the space audit log.