Notifications

The Notifications page (in the org sidebar) has two tabs. My notifications is available to everyone and manages your own run notifications for this organization. Organization appears when you have the notifications permission and manages org-wide channels, Slack connections, subscriptions, and the delivery log.

My notifications

My notifications lets you get notified when workflow runs in the current organization finish — without needing any admin permission.

Each notification can be delivered two ways:

Email — sent to your account address through the organization’s managed email channel.
Slack (direct message) — a DM to you, available after you connect your Slack identity with the Connect your Slack card below. The Delivery method picker disables Slack until then.

Each notification is a rule you control:

Repo / workflow / job glob — which runs to match (* matches everything).
Level — notify on the whole run, or per failing job.
On status — failed, success, and/or cancelled.

The Via column shows each notification’s delivery method. Toggle a notification off to pause it, or delete it to stop entirely.

My notifications are scoped to the organization you are viewing — they match that org’s runs and are delivered only to you (your account email or your own Slack direct message). Each user manages their own; you never see another member’s notifications, and they never see yours.

Organization

The Organization tab delivers a message when a run reaches a terminal state, over Slack or email. One message is sent per run — when several jobs match, they are listed in a single coalesced message rather than one per job.

Set-up has three parts:

Connect a Slack workspace via OAuth (only needed for Slack channels).
Add a channel — a Slack channel in a connected workspace, or an email channel.
Create a subscription that decides which runs/jobs deliver to which channel, and who receives them.

This tab is for organization-wide configuration and needs the notifications admin permission. Any member can manage their own self-delivery notifications (email or a Slack direct message) from the My notifications tab on this page — no admin permission required.

Slack connections

A Slack workspace connection is created by the Connect Slack button, which runs the OAuth install flow and stores an encrypted bot token. One connection per Slack workspace; reconnecting refreshes the token.

If a connection is disabled (for example, the bot token was revoked in Slack), a Re-authorize button re-runs the install flow to restore it.

Channels

A channel is a delivery target. Pick a type:

Slack: a channel in a connected workspace. Pick it from the workspace’s channel list, or enter a channel ID manually (e.g. C0123456789) for a private or unlisted channel the picker can’t show.
Email: sends a run-summary email; optionally set a from-name and reply-to. Recipients come from the subscription’s scope (below).

Add as many channels as you need — subscriptions reference them by name.

Each channel has a Test button that sends a synthetic notification through it so you can confirm a Slack or email connection works. A managed email channel labelled Email (managed) is provisioned automatically to back self-service email-to-self notifications; it cannot be deleted.

Subscriptions

A subscription decides which runs deliver to which channel, and (for email) who receives them. Each subscription has:

Level: run matches the whole run; job matches individual jobs (and lists every matching job in the coalesced message).
Scope (email): org, team, user, or triggering actor. A team scope emails every team member individually; a user scope emails that user. An org scope sends only to the recipient-override list — it never emails every member. A triggering actor scope is dynamic: it emails the person who triggered each run (the pusher or PR author), resolved per run — so the person who broke the build hears about it without being pre-subscribed. It needs no scope ID and requires an email channel.
Recipient emails (optional): an explicit address list that overrides the scope resolution. Required for an org-scoped email subscription.
Repo glob: restrict to repositories whose identifier matches (e.g. acme/*); * matches everything.
On status: the terminal statuses that trigger delivery (e.g. failed).

Addresses that have bounced or filed a complaint are suppressed automatically and skipped on every send.

The triggering actor scope resolves the run’s actor to a KiCI user by their linked provider identity. Anyone who has signed into the dashboard with their provider account is linked automatically, so they are notified without any extra setup. If the actor has no linked account (for example, a contributor who has never used KiCI), the run is recorded as a skipped delivery and no email is sent — KiCI never emails a commit address it has not verified. Encourage contributors to sign in with their provider account so build-failure notifications can reach them.

Each subscription shows its source. Subscriptions created in the dashboard are manual and can be edited or deleted here. Subscriptions managed by another source (such as infrastructure-as-code) are read-only in the dashboard and display a badge instead of edit controls.

Delivery log

The delivery log shows recent coalesced messages: the run, its terminal status, the delivery outcome (pending / success / failed), the per-recipient sent count (email), the issue reason on a skipped or failed row, and the attempt count. A delivery is retried with backoff on transient errors and provider rate limits.

Test notifications you send from a channel also appear here, marked with a Test badge and a — in the Run column, so you can confirm a channel is configured correctly without waiting for a real run.

The Issue column surfaces why a delivery was skipped or failed — for example, an actor-scope Slack subscription whose triggering actor has no roster entry shows slack_identity_unresolved. Add the actor to the roster below to tag them next time.

Actor tagging roster

The actor tagging roster maps a contributor to their Slack member id so that, when a run fails, the person who triggered it is @-mentioned in Slack — on top of any static mentions on the subscription.

Each entry keys on a subject — a KiCI user, a git login, or an email — and points it at a Slack member id. The Slack side is entered three ways, detected automatically from what you type: a Slack member id (U…, validated directly), an email (resolved to the member id via Slack), or an @handle / display name (matched once against the workspace member list and frozen to the resolved id).

The subject side is validated at add time:

A KiCI user or Email subject must match an existing KiCI user, or the add is rejected. Instead of pasting a raw id, pick the user from the searchable picker — type a name or email and select the person.
A Git login subject is stored as-is (it is the bridge for a contributor who has never signed into KiCI, so it need not map to any KiCI user).

The roster table shows each mapping resolved to the user’s email (id) rather than an opaque id, with a user not found tag when a previously-mapped user has since been removed. An admin manages the shared roster; any user can connect their own Slack account from their personal notifications using Connect Slack (Sign in with Slack). Actor tagging is best-effort — an unresolved actor falls back to the subscription’s static mentions and is recorded in the delivery log’s Issue column.

Connect your own Slack to unlock two things: Slack direct-message delivery for your personal notifications (pick Slack in the Delivery method picker when adding one), and getting @-mentioned when a run you triggered fails.

Click Connect Slack and sign in to Slack — Slack itself confirms which member you are, so there is no email to type and it works even when your Slack email differs from your KiCI email.

Pick the workspace first if more than one is connected. This maps your own account only; Disconnect removes it. To map by Slack member id or @handle, ask an admin.

Slack DM delivery needs the workspace’s Slack app to hold direct-message permission. A workspace connected earlier shows a Re-authorize prompt on the organization tab until an admin re-authorizes it.