Skip to main content

​
Overview

The Slack Integration page is the customer-facing setup flow for enabling Slack-based deployment and messaging for Genesis Data Agents. Actual Genesis Slack Integration page showing token fields, account linking, and setup steps.

​
What the page covers

  • Slack status,
  • account linking,
  • workspace token configuration,
  • guided setup steps,
  • deployment-specific instructions,
  • per-agent deployment actions.

​
Typical workflow

  1. Open Config -> Slack Integration.
  2. Follow the setup steps shown in the page.
  3. Provide the required Slack tokens.
  4. Save the Slack configuration.
  5. Deploy supported Genesis Data Agents into Slack.
In Genesis Desktop, Slack authorization opens in your system browser. Keep Genesis open while you approve access; the Slack status updates after authorization completes, and the deployment flow closes automatically. When you deploy or update a Slack-enabled agent, Genesis refreshes the live Slack runtime in place so the agent can come online without a full Genesis restart. Deactivated agents do not receive new Slack messages. If an agent is deactivated in Agents Center and Skills, Genesis drops inbound Slack input for that bot until it is reactivated.

​
Customer-facing note

The exact setup path can vary by deployment, especially when external-access approval or a public callback URL is required. Databricks Apps use Slack Socket Mode, so they do not need an ngrok tunnel for Slack message intake; the public App URL is still required for the OAuth callback and manifest links below. When installing a Slack app from a Databricks App deployment, Genesis requires a resolved public App URL for the OAuth callback and manifest links; it refuses the install rather than generating localhost URLs when that URL is unknown. See Databricks App public URL and OAuth callbacks for the URL settings and provider callback to register. The Slack deployment list shows supported customer-facing agents for the workspace. Internal system agents used for behind-the-scenes orchestration or recommendation flows do not appear in that list.

​
Working with Slack-linked threads

When SLACK_IMPORT_AVATARS=true (default false), Genesis can import a user’s Slack profile photo when they first message a bot and have no Genesis avatar. On Databricks Apps with durable storage enabled, imported avatars survive host replacement; see Deploying Genesis on Databricks — Durable SQLite stores. After you deploy an agent to Slack, the same conversation can continue in Genesis chat. Existing Slack threads reopen as the same thread, including after a Genesis restart, so Genesis does not re-import prior Slack history as a fresh prompt, and Slack-only reply guidance stays out of the visible transcript. If the thread is already visible in Genesis, you can keep replying while the live thread stream finishes attaching in the background. When Genesis sends a direct message or channel post from an active Genesis thread, the Slack post also includes an Open thread in Genesis footer so recipients can jump back to that exact conversation in the Genesis UI. Genesis prefers a configured public base URL for that footer and, when a deployed Genesis UI endpoint is already available, automatically uses that deployed URL for the thread link. Local development still falls back to the default dashboard URL, so Slack users outside local development should have a public Genesis URL they can open. Genesis also automatically reconnects the live Slack transport after brief disconnects, so admins usually do not need to redeploy an agent for temporary Slack interruptions. For long-running or streamed Slack replies, Genesis keeps updating the same in-thread reply as new content arrives instead of creating extra partial placeholder replies. Generated files still post into that same Slack thread, so reply context stays together even when the Slack transport briefly reconnects. When an agent overwrites a git-backed file at the same path, Genesis refreshes the download link so Slack recipients who click it get the latest file content, including when the byte size did not change. When a reply includes the embed link returned by _total_query_results, Genesis renders its saved totals as a Slack table, showing up to 99 data rows and 20 columns. For larger tables, Genesis also attempts a CSV attachment. See Data Connector Tools for the tool inputs and result limits. In live Slack conversations, Genesis also makes the Slack-native actions for direct messages, channel posts, reactions, and Slack user lookup available in that same thread automatically. Users do not need a separate Slack tool activation step, and Genesis carries the active Slack thread context behind the scenes. Accepted Slack messages create a row on Requests automatically by default (ticket_automation.auto_track_chat_requests). Follow-up messages in the same thread attach to that work item automatically. Each Slack-backed Request row also deep-links back to the originating Slack message when Genesis can resolve a permalink with the bot’s slack_app_token. When automatic tracking is disabled, or when a user asks to track work explicitly (track this, make this a work item), the agent can promote the conversation with promote_conversation_to_work instead.

​
Flow failure alerts in Slack

When a Genesis Flow fails with on_failure: notify_thread and the alert is delivered through Slack, Genesis opens (or reuses) a Slack-linked investigation thread with trusted failure context. The Slack notification prose is only a pointer — agents must not infer a root cause from it. Genesis injects an evidence-first investigation task that requires:
  1. inspect_flow_failure(run_id=...) before any causal claim.
  2. Reconciliation of the exact failed-task definition and error log with any bounded preceding-step evidence returned by inspection.
  3. A concrete root cause with every value from inspect_flow_failure.required_citations copied verbatim into visible assistant content (each citation as one contiguous label=value literal).
  4. Correction of the live Flow to a newer version, then run_flow_rca_verification with failed_run_id, root_cause, evidence_citations, and remediation_summary. This combined tool verifies the correction and durably writes the outcome plus protected gold — do not substitute a generic flow_action(RUN) because it lacks the trusted evidence linkage.
  5. When the terminal receipt reports task_durably_complete: true, restate the cited root cause and verified remediation in the next response. Do not call record_flow_rca_outcome after a successful terminal receipt. Use record_flow_rca_outcome(remediation_status='staged') only when correction cannot run yet.
If protected gold already exists for the failed run (for example after verification succeeded but a follow-up model response failed), retrying run_flow_rca_verification returns the canonical completed outcome without overwriting the protected record. See Flows → Flow failure investigation and RCA and flow_tools RCA tools.

​
dbt Cloud pipeline failure alerts in Slack

When a real dbt Cloud run fails and Genesis delivers the alert through Slack (for example from the proactive pipeline recovery presenter vignette or a ticket-driven dashboard anomaly), Genesis opens (or reuses) a trusted Slack investigation thread. The Slack notification prose is only a pointer — agents must not infer a root cause from it. For a tailored presenter version, the notification begins with its saved business story before the technical run context and evidence links. If Slack delivers the alert message before its metadata event, or the transport omits the alert metadata and blocks, Genesis can recover the trusted dbt Cloud handoff from the exact Slack delivery (sender, channel, target bot, message timestamp, and message text). If that durable handoff cannot be resolved, Genesis does not treat the message as ordinary bot chatter. Genesis also persists the trusted incident properties and investigation tool context before dispatching the alert to the agent, so a failed persistence step prevents an untrusted investigation from starting. Presenter recovery runs use the incident’s persisted dbt Cloud context and exact connection; see dbt_cloud_run_job for the required trusted incident parameters and matching rules. Genesis injects an evidence-first investigation task that requires:
  1. dbt_cloud_get(kind='run', run_id=...) for live status, run steps, logs, and artifacts before any causal claim.
  2. dbt_cloud_analyze_run(run_id=...) when the run failed, before stating a root cause.
  3. A concrete root cause and the smallest safe correction, proposed in the Slack thread with explicit approval before code changes or a recovery run.
  4. After the recovery run succeeds, dbt_cloud_verify_presenter_recovery with the trusted presenter_incident_id and job_id. Poll that same tool while it is still running. Never claim recovery until Prover returns PASS.
  5. When Prover returns FAIL, treat the reported mismatches as new remediation evidence: explain the exact mismatch, propose the smallest next correction on the same isolated branch, wait for explicit approval again, delegate that correction, rerun the same ordinary dbt job, and start a fresh Prover verification. Repeat only while Prover reports evidence-backed failures; stop on PASS or report the exact infrastructure blocker.
Follow-up replies in the same trusted Slack thread restore the original presenter incident owner’s identity from persisted investigation context, so later messages in that thread continue as the incident owner rather than the unrelated Slack user who sent the reply. See dbt_cloud_verify_presenter_recovery in the Genbot Toolkit. If a bot remains Configured and Active but stops responding to direct messages, admins can inspect the live Slack Socket Mode runtime and trigger a targeted reconnect without redeploying the bot. See API Reference for the /api/slack/bot/{bot_id}/runtime and /api/slack/bot/{bot_id}/reconnect admin routes. Slack transport now runs in a dedicated Genesis-managed worker runtime instead of the main web process. Lifecycle, warning, and error events from that runtime are forwarded into Genesis operational logs, so admins can monitor Slack connect, reconnect, disconnect, and message-receipt activity from Pulse Monitoring in the Live Logs view. Genesis starts those Slack worker subprocesses with the multiprocessing spawn start method by default (the same default used by the thread-service and iceberg workers). Spawn gives each child a private address space, which reduces copy-on-write memory growth on long-running deployments. Operators who need another start method can set GENESIS_SLACK_PROCESS_START_METHOD (for example fork or forkserver). On the default spawn path, Genesis does not start the optional Slack feature worker subprocess unless GENESIS_SLACK_FORCE_FEATURE_WORKER is set to true. In a Databricks App, Genesis checks the Slack worker periodically and can respawn it after an unexpected exit, so temporary worker-process failures do not require redeploying the app. This recovery is bounded by a per-child restart budget; see Child process supervisor settings.