Notifications.
Notification channels
What it is. Where AccessFlow sends review notifications — when a query is
submitted, approved, rejected, times out, or scores CRITICAL on AI risk. Wire
up the channels your team already lives in so reviewers act fast. Configure as many as you
like per organization (e.g. one Slack channel per team).
Configure it. Manage channels at /admin/notifications:
/admin/notifications → Add channel. The form swaps its lower half between Email, Slack, Webhook, Discord, Telegram, Microsoft Teams, PagerDuty, ServiceNow, and Jira fields when you change Type.- Open
/admin/notificationsand click Add channel. - Pick a type:
- Email — supply SMTP host, port, optional user / password, TLS, and the From address / display name. Leave the SMTP fields blank to fall back on the system SMTP.
- Slack — paste an incoming-webhook URL for one-way Block Kit messages (header, SQL preview, and a View in AccessFlow link). For interactive Approve / Reject buttons, configure a Slack app instead (see below).
- Webhook — supply a target URL and a signing secret. Every POST carries
X-AccessFlow-Signature: sha256=...computed from the body and the secret. - Discord — paste a channel webhook URL (Server Settings → Integrations → Webhooks). Optional username and avatar URL override the bot identity per-message. Messages render as a rich embed with the SQL preview in a fenced code block.
- Telegram — create a bot via @BotFather, add it to the target group/channel, and configure the bot token plus numeric chat ID. Messages use MarkdownV2 formatting.
- Microsoft Teams — paste the channel's Incoming Webhook (or Power Automate webhook) URL. Messages render as an Adaptive Card with a View in AccessFlow action button.
- PagerDuty — paste an Events API v2 integration routing key, pick a default severity (critical / error / warning / info), and choose which triggers page the channel: AI critical-risk query, review timeout, and/or routing-policy escalation. Other events never fire it. AccessFlow sends a
triggerevent with a query-stable dedup key so repeat events fold into one incident. - ServiceNow — supply the instance URL plus a username / password allowed to create incidents via the Table API, optionally an assignment group and urgency (1–3), and choose which triggers open an incident: query rejected, review timeout, and/or routing-policy escalation. Created incidents link back onto the query detail page.
- Jira — supply the site URL, an account email + API token, the target project key, and optionally an issue type (default Task); pick the same trigger set. Issues are created via REST v2 with an
accessflowlabel and link back onto the query detail page.
- Bi-directional status sync (ServiceNow / Jira). Toggle Bi-directional status sync on the channel and set a webhook secret; then point a ServiceNow Business Rule / Jira Automation rule at
POST /api/v1/integrations/servicenow/webhook/{channelId}(or…/jira/webhook/{channelId}) sending{"external_id", "status", "resolution", "actor"}signed withX-AccessFlow-Timestamp+X-AccessFlow-Signature: sha256=HMAC-SHA256(secret, "v1:{timestamp}:{body}"). Ticket status updates flow onto the query detail page, and a resolution matching the channel's approve / reject status lists decides a query still awaiting review — attributed to the ticketing system in the audit log. - Send a test event. After saving, each channel card has a Test button — the dispatcher fires a synthetic event and reports delivery success.
- Edit or remove. Each card also has Edit and Delete buttons. Deleting a channel is immediate (hard delete) — there is no soft-delete, but webhook retries already scheduled before the delete still complete.
Sensitive config fields (SMTP password, webhook secret, Telegram bot token, PagerDuty routing key, ServiceNow password, Jira API token, ticketing webhook secret) are AES-256-GCM encrypted at rest and are never shown in plaintext after the channel is saved.
+30s, +2 min, +10 min. Tune the
delays via ACCESSFLOW_NOTIFICATIONS_RETRY_FIRST /
_SECOND / _THIRD. Failed deliveries log ERROR
but never affect query workflow state.
Tune it. ACCESSFLOW_PUBLIC_BASE_URL sets the link embedded in
messages (default http://localhost:5173); retry delays are
ACCESSFLOW_NOTIFICATIONS_RETRY_FIRST / _SECOND / _THIRD
(PT30S / PT2M / PT10M). For air-gapped installs that
route through an internal proxy, override
ACCESSFLOW_NOTIFICATIONS_TELEGRAM_API_BASE_URL
(https://api.telegram.org/) and
ACCESSFLOW_NOTIFICATIONS_PAGERDUTY_API_BASE_URL
(https://events.pagerduty.com/). The inbound ticketing-webhook signature
window is ACCESSFLOW_NOTIFICATIONS_TICKETING_SIGNATURE_TOLERANCE
(PT5M).
Slack app — Approve / Reject from Slack
Beyond the one-way Slack webhook channel, an admin can connect a Slack app
at /admin/slack so reviewers act on requests without leaving Slack. Create the app
in Slack's console, then paste its App ID, Bot token, Signing secret,
and a default channel ID. When an app is active, review-request messages are posted via
the bot token and carry Approve and Reject buttons.
- Each reviewer links their Slack identity once. On
/profile→ Slack account, click Generate link code, then run/accessflow link <code>in Slack. The code is single-use and short-lived (ACCESSFLOW_NOTIFICATIONS_SLACK_LINK_CODE_TTL, default 10 min). - Clicking Approve / Reject runs through the same review service as the UI — a reviewer can never approve their own query, and role / stage checks apply identically. The original Slack message updates in place with the decision.
Inbound clicks are verified by the Slack signing secret (HMAC over the raw body, with a
timestamp/replay window set by ACCESSFLOW_NOTIFICATIONS_SLACK_SIGNATURE_TOLERANCE,
default 5 min). The bot token and signing secret are AES-256-GCM encrypted at rest and never
returned by the API. Point your Slack app's Interactivity request URL at
/api/v1/integrations/slack/actions and its slash command at
/api/v1/integrations/slack/commands.
/admin/slack — connect the interactive Slack app (bot token + signing secret).System SMTP
What it is. The fallback mail server for transactional email — password resets, user invitations, and any email notification channel that doesn't carry its own SMTP settings. Set it once per org so those emails can go out.
Configure it. On /admin/notifications, the first card is
System SMTP:
/admin/notifications → System SMTP card → Configure.- Open
/admin/notifications. The first card is System SMTP — click Configure (or Edit if it's already set). - Fill the form. Host, port (587 for STARTTLS, 465 for implicit TLS), optional username and password, STARTTLS toggle, and the From address — required and validated as an email. The password field shows "Leave blank to keep the existing password" when editing, so secrets aren't echoed back.
- Send a test email. After saving, the card exposes a sink-address input + Send test button so you can verify deliverability without firing a real workflow event.
The password is AES-256-GCM encrypted at rest. Delete the row from the same card if you'd rather rely solely on per-channel email overrides.