Notifications

Notifications are how Vigilator gets a member's attention - inside the app, with count badges for the work assigned to them, and outside it, with emails when work arrives and nobody is around to take it. Both are configured under Settings > Notifications.

The settings are organisation-wide rather than per member. Every change saves immediately, any member can view the tab, and changing it needs the organization.update permission (see access control).

Sidebar badges

With Show assignment badges in the sidebar on (the default), each member sees a red count next to Inbox and Live View in the sidebar: the number of open interrupts and active sessions assigned to them that they haven't opened yet. The point is cross-queue visibility - a member working through the inbox still notices when a session is handed to them in Live View, and vice versa.

A badge counts an item until its assignee opens it - the interrupt in the inbox, or the session's transcript in Live View. It is per member, so two members never see each other's counts, and it's unread rather than open: an interrupt you have already looked at doesn't keep counting against you while you decide it. A few things reset an item to unread:

• It is assigned - by workload management on arrival, by a colleague, or by coverage moving it from an offline member.
• It is re-assigned to someone else, in which case it becomes unread for them instead.
• It is escalated to the manager review queue.

Answering an interrupt or ending a session removes it from the count regardless. Counts refresh every half minute or so and cap at 99+. Turning the toggle off hides the badges for every member of the organisation.

When nobody is online

The second panel deals with the situation workload management cannot solve on its own: an interrupt arrives, or an agent starts a session, and no member of the organisation is online. It applies to the inbox and Live View alike, and only appears once at least one of the two surfaces has online mode switched on in Workload Management - without online mode, Vigilator has no notion of who is online to begin with.

Pick what should happen:

• Leave unassigned (default) - the work simply queues. The first member to come online is handed it automatically.
• Notify the escalation chain - the work still queues, but Vigilator also starts emailing the escalation chain so that somebody comes and takes it.

The escalation chain

The escalation chain is an ordered list of members. When the chain is triggered, Vigilator emails them one at a time, waiting for the situation to resolve before moving on:

Build the chain by adding members from the picker (each member can appear once) and reorder it with the arrows - the first member listed is contacted first. With two or more members in the chain, Escalate to the next member after sets how long each step waits before the next member is emailed: 5 minutes, 10 minutes (the default), 30 minutes or 1 hour.

The situation counts as resolved as soon as either of these is true:

• A member comes online. Signing in is enough, and it drains the queue - the queued work is handed to them under the normal assignment rules. So does choosing Become online from the sidebar.
• The queued work is gone - it was picked up by hand, answered, or its session ended.

Every step re-checks before sending, so once the situation is handled the chain stops without emailing anyone further. It also stops if the setting is switched back to Leave unassigned mid-chain. A member who has left the organisation is skipped rather than emailed.

Two limits keep the chain from becoming noise:

• A chain starts at most once an hour per queue (inbox interrupts and Live View sessions are counted separately). A burst of overnight interrupts sends one round of emails, not one per interrupt.
• Only the nobody online case triggers it. If people are online but everyone is at their capacity limit, the work queues quietly - that's expected load, not a coverage gap.

The email

Each step's email tells the recipient how many interrupts are waiting in the organisation's inbox (or how many agent sessions are running) with nobody online to take them, where they sit in the chain ("step 2 of 3"), that signing in stops the chain, and links straight to the inbox or Live View. Emails are sent to the address on the member's Vigilator account.

Other emails

The Notifications tab controls the two things above. Vigilator also sends a few emails that are not configurable because they are about your account or your integrations rather than your workload:

• Account emails - verification, sign-in codes, password resets and organisation invitations.
• Webhook delivery alerts - the organisation's owner is emailed when a webhook endpoint runs out of delivery retries, and again if it is disabled automatically for failing repeatedly.

Permissions