> ## Documentation Index > Fetch the complete documentation index at: https://docs.sazabi.com/llms.txt > Use this file to discover all available pages before exploring further. # Route notifications > Route issue and system events to the right people and channels — personal channels by your own preference, shared channels by delivery rules. 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**](https://app.sazabi.com/settings/notifications) (personal) and shared delivery at the project [**Settings > Notifications**](https://app.sazabi.com/settings/project-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, 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 reopened** — a resolved or ignored issue was reopened, by a person, Sazabi's agent, or a synced tracker task. Never held back by the daily limit; in Slack and Microsoft Teams it is a new message, with what came back threaded under it. A rule that sends Issue updated sends it too. * **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 eight of them can be routed to shared destinations: **Issue triggered**, **Issue resolved**, **Issue ignored**, **Issue rejected**, **Issue updated**, **Issue reopened** (wherever a rule sends 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). | Personal channels | Shared channels | | - | - | | In-app (the bell feed) | Slack channel | | Slack DM | Microsoft Teams channel | | Email | Webhook | | SMS | PagerDuty | | | incident.io | | | Rootly | 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](https://docs.sazabi.com/catalogs/integrations/slack.md)), Microsoft Teams ([Microsoft Teams integration](https://docs.sazabi.com/catalogs/integrations/microsoft-teams.md)), PagerDuty ([PagerDuty](https://docs.sazabi.com/catalogs/integrations/pagerduty.md)), incident.io ([incident.io](https://docs.sazabi.com/catalogs/integrations/incident-io.md)), and Rootly ([Rootly](https://docs.sazabi.com/catalogs/integrations/rootly.md)). Webhooks are covered in [Configure webhooks](https://docs.sazabi.com/guides/administer/webhooks.md). ## 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**](https://app.sazabi.com/settings/project-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](https://docs.sazabi.com/reference/cli.md)). `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. ```bash theme={"system"} sazabi notifications delivery-rules options # See routable destinations, events, and conditions sazabi notifications delivery-rules create \ --notification-type issue_triggered \ --destination slack_channel: \ --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**](https://app.sazabi.com/settings/notifications) — there is no CLI command to change your personal preferences; the CLI manages shared delivery rules only. ## Steps **Step 1** ### Set your personal preferences Go to [**Settings > Notifications**](https://app.sazabi.com/settings/notifications) (the personal page) and choose which channels receive which event types. You should see in-app and email already on. Turn on Slack DM or SMS if you want those. **Step 2** ### Add a shared delivery rule Open the project [**Settings > Notifications**](https://app.sazabi.com/settings/project-notifications) page, then **Delivery rules > Add delivery rule**. Pick the event type (for example **Issue triggered**), choose a shared destination (a connected Slack channel), and optionally add a severity condition and either a component or an owning-team condition. Save. You should see the rule listed under **Delivery rules**. From the CLI, this step is `sazabi notifications delivery-rules create` (see [Delivery rules](#delivery-rules) above). **Step 3** ### Confirm the destination is connected The rule can only target a destination whose integration is connected. If no destinations are available, connect the integration first under [**Settings > Integrations**](https://app.sazabi.com/settings/integrations). ## 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 > [card] [Slack integration](https://docs.sazabi.com/catalogs/integrations/slack.md) > > Connect Slack for channel delivery and issue cards. > [card] [Configure webhooks](https://docs.sazabi.com/guides/administer/webhooks.md) > > Deliver events to an HTTP endpoint you control. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.