Notification settings

Everything that decides how alerts and emails reach people lives at Settings → Notifications. It replaces a set of screens that used to be spread across Settings, Monitoring, Alerts and PSA → Workflows — the old locations still work and redirect or link here.

Two ideas underpin the layout:

• Triggering and delivery are separate. Whether an alert fires is one decision (thresholds, anomaly sensitivity, per-asset toggles). Where it goes once it fires is another (alert templates, channels). The tabs keep the two apart deliberately.
• Org-level config lives here; per-entity config stays on the entity. "Alert when this asset goes offline" belongs on the agent, not on a global settings page. The hub links to those surfaces rather than duplicating them.

The tabs

Channels

Org-wide default webhooks for Slack, Microsoft Teams and Discord, each with a test button. Alert templates use these defaults unless a template specifies its own override URL.

For Teams, note that Microsoft retired the classic Incoming Webhook connectors (webhook.office.com) in May 2026 — create a Workflows webhook instead (channel → ... → Workflows → "Send webhook alerts to a channel", then copy the link). See Alert templates for the details and caveats.

Alert delivery

The alert templates — who gets emailed, which webhook fires, which chat channel is posted to when an asset alert goes off. Templates resolve through a cascade: agent → site → client → org default, most specific wins.

Every organisation has one Default alerts template marked as the org default. It ships with every channel disabled — nothing sends until you enable a channel and add recipients — but it guarantees the cascade always resolves. If you only do one thing on this page, put your NOC address in the default template's email recipients and enable the email channel: from then on every alert without a more specific template reaches you.

The template editor covers all channels — email, generic webhook, Slack, Teams and Discord — each with its own enable toggle, its own minimum severity (all severities / warnings and above / errors only) and a Send test button, and includes a Template variables reference listing every placeholder the dispatcher supplies (AgentHostname, Severity, Message, …). Chat channels left without a webhook URL use the org defaults from the Channels tab. The classic setup is one default template with email on all severities and Slack on errors only.

See Alert templates for the full cascade reference and worked examples.

Alert triggering

Controls that decide whether an alert fires in the first place:

• Anomaly detection — per-check-type toggle, sensitivity (z-score based) and rolling window.
• Links to the per-entity toggles that live on their own surfaces:
  • Agent offline alerts — per-asset toggle on the agent's Edit details dialog. Servers alert on offline by default; workstations don't.
  • Check thresholds — warn/error thresholds and failures-before-alert, per check.
  • Network device rules — metric/threshold alert rules per device.
  • Domain monitors — SSL / DNS / WHOIS expiry checks per monitor.

Ticket emails

The PSA system notifications — auto-acknowledge new email tickets, notify the requester on a public reply, notify the assignee on a comment. Each has an on/off toggle, an editable template, and advanced guards (per-recipient cooldown, business hours, max fires per ticket).

These are off by default for new organisations: nothing emails your clients until you opt in. See Notifications for details and template variables.

In-app notifications are separate

The toggles on this tab control email only. In-app notifications, the toast in the web app and the native desktop notification in OpsMerge Desk, are delivered independently and are not affected by these rules.

You receive an in-app notification when someone replies on a ticket you are assigned to or watching, when you are @mentioned in an internal comment, and when a user replies in a chat session you started. In every case the person who performed the action is never notified of their own change, and notifications generated by workflow automation are suppressed entirely.

This split is deliberate. Turning off Notify assignee on a comment stops the email but keeps the live toast, so a technician at their desk still sees the reply without their inbox filling up. Each technician can mute individual categories, and set quiet hours, in Desk under Settings, Notifications.

Desk keeps delivering notifications while it is locked or running in the background, not only while it is open and unlocked — that is the point of a desktop helpdesk app. On a locked screen the toast text is generic ("You have a new notification") so no ticket detail is exposed; unlock to see the full message. If notifications are not arriving, Settings → Diagnostics shows whether the live feed is connected and includes a Send test notification button; if the test toast does not appear, the operating system is suppressing it (Windows Focus Assist / Do Not Disturb, or the per-app notification setting for OpsMerge Desk).

Watchers are the exception that also emails: anyone watching a ticket gets an email on comments and updates regardless of the toggles above, because watching is an explicit per-ticket opt-in. Stop watching the ticket to stop those.

Email

Where the mail itself leaves from. Ticket replies, invoices and alert emails all ride the outbound email gateway — sending domains, delivery reporting, the blocklist and per-address suppressions are managed on the email gateway screen, linked from this tab.

Delivery reliability

A few behaviours worth knowing, all automatic:

• Recovery notifications. When an alert resolves ("back to normal"), the resolution is delivered through the same channels as the original alert.
• Retry sweep. If a notification fails to send (mail server blip, webhook endpoint down) or is lost to a restart, a background sweep retries undelivered notifications for active alerts every few minutes, for up to 24 hours.
• Email fallback. Alert email prefers your per-org SMTP settings if configured; organisations without SMTP fall back to the platform email gateway automatically, using your verified sending domain.
• Your branding. Alert emails carry your organisation's branding — the invoice logo and legal footer from your billing configuration, with your name in the subject prefix — the same envelope your invoice emails use. Nothing configured falls back to the platform brand.
• Device links. The device hostname in default emails and chat cards links straight to that device's page in the portal (on your custom domain when one is active).