Skip to main content
Settings

Notifications

How notification rules, templates, and personal preferences combine to decide who hears about what.

Three layers decide whether a notification reaches someone: a tenant notification rule routes an event to recipients over a channel, a template shapes the message, and the recipient's personal preferences get the final word on delivery — with one deliberate exception for compliance events.

Notification rules

Settings → Notifications → Rules (permission notification.rule.manage) defines the routing. A rule binds:

  • Event type — a dotted event key such as incident.created, incident.sla.breached, or change.cab.quorum_met.
  • Channel — in-app, email, or webhook.
  • Recipients — one of four selector kinds: a role (every holder of a role key), a group, a named user, or a ticket field (assignee, requester, or reporter of the record the event is about).
  • Condition (optional) — a single field/operator/value test on the event, over fields like severity, priority, status, or change_type, with operators equals, not equals, and in list.
  • Active — rules are active by default; deactivate rather than delete to keep history.

Rules only route. They never change a record — escalation and assignment automation belongs to business rules.

Templates

Settings → Notifications → Templates manages message content: a template key, a locale, a subject, and a Markdown body. Templates are per-locale; a recipient whose language has no template falls back to English.

Personal preferences

Settings → Notifications on the personal side gives each user:

  • Channel switches — email, in-app, webhook, and push, each on by default.
  • Quiet hours — a daily window, evaluated in the user's own declared timezone (never the server's).
  • Category and per-event mutes — silence a whole category, or a single noisy event key (say, incident.sla.breached) without muting its category.
  • Digest frequency — instant delivery by default.
  • Snooze — a temporary snooze-until timestamp.

The compliance exception

The compliance category can never be muted — not by category mute, not by event override. The service layer rejects the attempt. Regulatory deadlines (DORA and NIS-2 reporting clocks among them) depend on the responsible people finding out; a personal preference is not allowed to silently break that.

Separately, an active maintenance window can suppress notifications for the systems under maintenance, so planned work does not page anyone.