How to Build a Slack Slash-Style Support Bot That Answers from Your Knowledge Base

Let an agent ask a support question from Slack and get a grounded, source-cited answer back in seconds, drawn straight from your own support documentation in Spojit.

What This Integration Does

Support agents lose time hunting through wikis, PDFs, and old tickets for the one paragraph that answers a customer's question. This workflow turns Slack into the front door for that knowledge. An agent triggers a Slack interactivity action (for example, a slash-style shortcut or message action) that posts a question into Spojit. Spojit searches a Knowledge collection of your support docs, has Miraxa compose a concise answer that quotes only what the docs actually say, and returns that answer with citations back to the same Slack thread. The agent never leaves Slack and always sees where the answer came from.

The run model is synchronous-plus-follow-up. Slack sends an HTTP POST to your workflow's Webhook trigger URL, verified by HMAC using the Slack signing scheme, and expects a reply within about three seconds. A fast Response node returns an immediate acknowledgement to Slack so the action does not time out, while the rest of the workflow keeps running: a Knowledge query retrieves the most relevant doc chunks, a Connector node in Agent mode writes the grounded answer with a fixed Response Schema, and a Slack send-message call posts the finished answer as a threaded follow-up. Each request is independent and stateless: re-running the same question simply searches the collection again and posts a fresh answer, so replays are safe.

Prerequisites

A Slack connection in Spojit (Connections -> Add connection -> Slack) with permission to post messages to the channels your agents use.
A Slack app of your own with an interactivity (or slash command) request URL you can point at Spojit, and access to its Signing Secret.
A Webhook signing connection configured with the Slack scheme, holding that Slack Signing Secret so Spojit can verify each request is genuinely from Slack.
A persistent Knowledge collection containing your support documentation (FAQs, troubleshooting guides, policy pages). Create it under the Knowledge section of the sidebar with New Collection, then Upload Document and Upload & Embed each file. Note which embedding model the collection uses.
The Slack channel ID where follow-up answers should be posted (or you can read it from the incoming Slack payload).

Step 1: Receive the Slack request with a Webhook trigger

Add a Trigger node and set its type to Webhook. In the trigger settings, attach the Webhook signing connection that uses the Slack scheme so every incoming request is HMAC-verified against your Slack Signing Secret. Unverified requests are rejected before any step runs. Copy the generated trigger URL and paste it into your Slack app as the interactivity request URL (or slash command request URL).

Slack posts a form-encoded body; Spojit parses it and exposes it as {{ input }}. The agent's question arrives in a field such as {{ input.text }}, the originating channel in {{ input.channel_id }}, and the user in {{ input.user_id }}. The webhook returns 202 with an executionId by default, but for Slack you want a fast custom reply, which you build in the next step.

Step 2: Acknowledge Slack immediately with a Response node

Slack requires a reply within roughly three seconds or it shows the agent a timeout error. Add a Response node right after the trigger and return a small acknowledgement payload so Slack is satisfied while the slower knowledge and AI steps continue. Keep this node first and lightweight: do not query the knowledge base before it.

{
  "response_type": "ephemeral",
  "text": "Searching the knowledge base for you, one moment..."
}

This message shows only to the agent who triggered it. The real answer arrives a moment later as a threaded message in Step 5.

Step 3: Retrieve cited support docs with a Knowledge query

Add a Knowledge node set to Query mode. Choose your persistent support-docs Collection, and make sure its embedding model matches the one used when you uploaded the documents. Set Prompt to the agent's question, set Result Count to a small number such as 5 so you retrieve the most relevant passages, and pick a Model for synthesis. Save the retrieved material to an Output Variable such as kb.

Prompt: {{ input.text }}
Collection: Support Docs
Result Count: 5
Output Variable: kb

The query returns the relevant chunks plus the source documents they came from, which you reference when composing the cited answer in the next step.

Step 4: Compose a grounded answer with an Agent-mode Connector node and Response Schema

Add a Connector node in Agent mode and let Miraxa, the intelligent layer across your automation, turn the retrieved passages into a clean answer. Instruct it to answer only from the supplied material and to refuse politely if the docs do not cover the question. Pass the question and the knowledge result into the prompt with {{ input.text }} and {{ kb }}.

Attach a Response Schema so the output is reliable structured JSON rather than free text. This forces the answer and its citations into named fields you can format predictably.

{
  "type": "object",
  "properties": {
    "answer":   { "type": "string" },
    "sources":  {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "title": { "type": "string" },
          "quote": { "type": "string" }
        }
      }
    },
    "answered": { "type": "boolean" }
  },
  "required": ["answer", "answered"]
}

Save the result to an Output Variable such as reply. You now have {{ reply.answer }}, a {{ reply.sources }} list, and an {{ reply.answered }} flag you can branch on if you want to handle "not found" differently.

Step 5: Post the answer back to the Slack thread

Add a Connector node on the Slack connector in Direct mode and pick the send-message tool. Set channel to {{ input.channel_id }} so the answer lands in the same channel the agent asked from, and set text to the composed answer. Include the citations so agents can verify the source. If the original Slack action carried a message timestamp, set thread_ts to it so the reply threads under the question instead of cluttering the channel.

channel:   {{ input.channel_id }}
text:      {{ reply.answer }}

Sources:
{{ reply.sources }}
thread_ts: {{ input.message_ts }}

For richer formatting you can pass a Block Kit array to the optional blocks field, with text kept as the plain-text fallback. Either way, the agent sees a grounded answer with its citations in seconds, all inside Slack.

Step 6: Optional - handle questions the docs cannot answer

To avoid posting a guessed answer, add a Condition node before the Slack post that checks {{ reply.answered }}. On the false branch, use send-message to reply with a short "I could not find this in our docs, escalating to a specialist" note and, if you like, a Send Email node to alert your support lead. This keeps the workflow honest about its limits and routes hard questions to a human.

Tips

Keep Result Count low (around 5). More chunks rarely improve the answer and add cost and latency that eat into Slack's timeout window.
Always answer first with the Response node, then do the slow work. The acknowledgement message reassures the agent while the knowledge and Agent-mode steps run.
Use the SAME embedding model for querying that you used when embedding the collection, or relevance will degrade.
Tell Miraxa in the Agent-mode prompt to quote the docs verbatim in the sources field. Visible citations build trust and make wrong answers easy to spot.

Common Pitfalls

Timeout errors in Slack: if you query the knowledge base before the Response node, Slack times out. The Response node must run first and return quickly.
Signature failures: if the Slack signing scheme is not selected on the Webhook connection, or the Signing Secret is wrong, every request is rejected. Confirm the secret matches your Slack app exactly.
Empty or stale answers: a collection with no documents, or docs you forgot to re-embed after editing, returns nothing useful. Check document Status is READY in the collection table.
Wrong field names from Slack: slash commands and interactivity payloads use different field names. Inspect the parsed {{ input }} in a test run before wiring up {{ input.text }} and {{ input.channel_id }}.

Testing

Start with a tiny collection of two or three documents whose answers you already know. Trigger the Slack action with a question those docs clearly cover and confirm the threaded reply quotes the right source. Then ask a question the docs do not cover and confirm the {{ reply.answered }} branch posts the escalation message rather than inventing an answer. Open the execution in Spojit's run history to inspect the Knowledge output and the Agent-mode result at each step. Once both the found and not-found paths behave correctly on this small scope, point the workflow at your full support-docs collection and share the Slack action with your team.