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.

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.

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. Terminal issue events (resolved, ignored) stay in the bell feed by default but skip email, so routine closes 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 two conditions:

• Match by component — route only issues linked to a named component.
• Match by severity — route only issues at or above a minimum severity (medium, high, or critical).

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, scope your rules with a Match by severity condition so only higher-severity issues route out — rather than adding broad rules that match every event.

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

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

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 a test issue in the project inbox (or open one with sazabi issues create --sample), 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