Route notifications

Notifications tell you when something happens in Sazabi — an issue opens, an issue is resolved, an automation fails. This guide covers what triggers a notification, the channels it can reach, and how to control routing. Configure personal delivery at Settings > Notifications (personal) and shared delivery at the project Settings > Notifications page.

What triggers a notification

Notifications come from a fixed catalog of types. The highest-signal ones are issue lifecycle events:

• Issue triggered — the agent opened a new issue.
• Issue resolved — an issue was resolved.
• Issue ignored — an issue was ignored.
• Issue updated — an open issue changed: its severity went up, it came back after it was resolved, or it now affects another component. Sent at most once per issue a day unless the severity rises again; in Slack and Microsoft Teams it is a reply under the issue's alert.
• Issue still open — an issue is still open, 1, 2, 3, 7, 14, 21 and 28 days after it opened, then monthly. Resolving or ignoring it stops the reminders; reopening it starts them again.

Automation events also notify:

• Automation finished — a run completed.
• Automation run failed — a run exited non-zero.

Additional types cover billing, organization, security, integration, and project-resource events. Each type is either organization-scoped or project-scoped — the scope decides which membership its recipients are drawn from. Organization-scoped types (such as billing and security) reach members over their personal channels only, because shared destinations are owned by projects. Project-scoped types also reach personal channels, and seven of them can be routed to shared destinations: Issue triggered, Issue resolved, Issue ignored, Issue rejected, Issue updated, Issue still open (Slack, Microsoft Teams, and webhooks only), and Automation run failed.

Channels

A channel is either personal (each user configures their own) or shared (a project admin configures one destination for the whole project).

In-app and email are on by default for a new user; the other personal channels are opt-in. Issue lifecycle events (triggered, resolved, ignored) and failed automation runs stay in the bell feed by default but skip email, so noisy operational events do not fill your inbox.

For channel-specific setup, see the integration pages: Slack (Slack integration), Microsoft Teams (Microsoft Teams integration), PagerDuty (PagerDuty), incident.io (incident.io), and Rootly (Rootly). Webhooks are covered in Configure webhooks.

Personal vs shared

The two kinds are gated differently, and that difference is the model:

• Personal channels are gated by your own preference. Nobody can opt you in, and your preferences are global to you across every organization and project.
• Shared channels are gated by a delivery rule. A shared destination receives an event only when an enabled rule names both that destination and that event. No rule means no shared delivery; individual users cannot opt a shared destination out.

Delivery rules

A delivery rule routes an event type to one or more shared destinations, with optional conditions. Create one at the project Settings > Notifications page under Delivery rules > Add delivery rule.

A rule matches on the notification type first, then applies its conditions. Issue events support three conditions:

• Match by component — route only issues linked to a named component.
• Match by owning team — route only issues whose component is owned by a listed team, so a team's rule stays current as components move to and from it with no rule edit.
• Match by severity — route only issues with the severities you select (low, medium, high, critical). The dashboard shows this condition as Severity is one of. Select each severity you want; selecting high alone does not include critical.

A rule can carry a component condition or an owning-team condition, never both; a rule that wants both writes two rules.

Delivery is positive: a rule only ever adds delivery, so an issue reaches a shared channel only when some rule routes it there. To keep a noisy project quiet, add a Match by severity condition that selects only the severities you want to see — for example, high and critical — rather than adding broad rules that match every event.

Delivery rules match the exact severities you select. Task creation rules work differently: their severity condition reads Severity is at least, so they include the severity you pick and every severity above it.

You can also manage delivery rules from the CLI instead of the dashboard (see CLI reference). sazabi notifications delivery-rules options lists the valid event types, destinations, and severities; sazabi notifications delivery-rules create adds a rule, sazabi notifications delivery-rules list shows the current ones, and sazabi notifications delivery-rules update / delete edit or remove one. sazabi notifications channels get inspects the project's configured channels.

sazabi notifications delivery-rules options   # See routable destinations, events, and conditions
sazabi notifications delivery-rules create \
  --notification-type issue_triggered \
  --destination slack_channel:<channel-id> \
  --severity high \
  --severity critical

--destination takes a channel:key pair; --notification-type, --destination, --component-id, --team-id, and --severity all repeat to build a rule that fans out to several destinations or matches several conditions. --component-id and --team-id are mutually exclusive on one rule.

Personal notification preferences (which of your own channels receive which events) are set in the dashboard under Settings > Notifications — there is no CLI command to change your personal preferences; the CLI manages shared delivery rules only.

Steps

Verify

Trigger a real issue event you can observe. Resolve or re-open an issue in the project inbox (the test issue Sazabi created with your first project works; creating it sent no notification), and confirm the issue card posts to the shared Slack channel named in your rule within a minute. If nothing arrives, check that the rule names both the event type and that destination, and that the issue's severity meets any minimum-severity condition on the rule.

Further reading