Documentation

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:

Add notification channel modal with name, channel type selected as EMAIL, active toggle on, and conditional SMTP fields revealed — host, port, user, password, TLS toggle, from address, and from name.
/admin/notificationsAdd channel. The form swaps its lower half between Email, Slack, Webhook, Discord, Telegram, Microsoft Teams, PagerDuty, ServiceNow, and Jira fields when you change Type.
  1. Open /admin/notifications and click Add channel.
  2. 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 trigger event 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 accessflow label and link back onto the query detail page.
  3. 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 with X-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.
  4. Send a test event. After saving, each channel card has a Test button — the dispatcher fires a synthetic event and reports delivery success.
  5. 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.

Webhook retry policy. One immediate attempt plus three scheduled retries at +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.

  1. Each reviewer links their Slack identity once. On /profileSlack 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).
  2. 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.

Slack app configuration at /admin/slack with fields for App ID, default channel ID, masked bot token and signing secret, an Active toggle, and Save / Send test message buttons.
/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:

System SMTP configuration modal with host, port (587), optional username, password, STARTTLS toggle, from-address, and optional display-name fields.
/admin/notificationsSystem SMTP card → Configure.
  1. Open /admin/notifications. The first card is System SMTP — click Configure (or Edit if it's already set).
  2. 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.
  3. 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.