> ## Documentation Index > Fetch the complete documentation index at: https://docs.genesiscomputing.com/llms.txt > Use this file to discover all available pages before exploring further. # Activate Genesis Data Agents On Slack > Connect Slack to Genesis so users can deploy and message Genesis Data Agents from a Slack workspace. ## 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](/docs/User-Guide/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](/docs/deployments/Databricks/Genesis-On-Databricks#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](/docs/deployments/Databricks/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](/docs/Genbot-Toolkit/Data-Connector-Tools#_total_query_results) 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](/docs/User-Guide/Work-Center) 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](/docs/User-Guide/Flows#flow-failure-investigation-and-rca) and [`flow_tools` RCA tools](/docs/Genbot-Toolkit/Additional-Tool-Groups#flow-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`](/docs/Genbot-Toolkit/Dbt-Cloud-Tools#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`](/docs/Genbot-Toolkit/Dbt-Cloud-Tools#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](/docs/Genesis-API/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](/docs/User-Guide/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](/docs/Setup/Advanced-Settings#child-process-supervisor). ## Related pages * [Users and Roles](/docs/Setup/Users-And-Roles) * [OAuth Providers](/docs/Setup/OAuth-Providers)