Connecting Slack
Every Slack connect button opens the same Connect Slack dialog: Add channel under Integrations → Channels, Add integration → Slack, Connect Slack in the Slack MCP setup and in a notification sink, and the Slack connection field when you add an agent. It asks which app connects your Slack, then what the app is for (Chat, Slack MCP or Both), and says what each choice creates before anything is connected. A step with only one possible answer is skipped.
On a self-hosted control plane, your own Slack app is the only one, so the dialog starts at what the
app is for.
Choose your own app when you need the Slack MCP, want to own the app’s name and permissions, or work
under a security policy that allows Socket Mode apps only. For the Slack MCP, a Slack admin must
approve the app: Slack serves its MCP only to internal apps and apps published in the Slack
Marketplace. Chat runs through one app at a time, but for the Slack MCP alone you can connect your
own app and keep chat on KAOP’s app.
KAOP’s Slack app
1
Choose KAOP's Slack app
Choose KAOP’s Slack app, then Authorize in Slack.
2
Approve the app in Slack
Approve KAOP in the Slack tab that opens. KAOP connects Slack as soon as you approve. If Slack
is already connected to your account, the Slack tab says so and there is nothing else to do. If
setup fails, the tab says why and what to do next.
3
The channel appears in KAOP
The dialog picks the connection up automatically, and the channel is ready to route messages.
Your own Slack app
You create the app in Slack from KAOP’s manifest, install it, and paste its tokens into the dialog. KAOP checks each token with Slack before saving anything. The steps, who the Slack MCP acts as, replacing tokens and disconnecting are in Your own Slack app.Channel status
One channel represents one Slack account connection. You can rename it, pause it, resume it, or delete it from its page. While connected, a channel on your own Slack app has Replace tokens and Disconnect instead of delete.revoked is distinct from paused on purpose: Resume brings a paused channel back, while a
revoked one needs Slack connected again. KAOP verifies its Slack credentials with a live check and
reacts to Slack’s own revocation events, so a dead connection surfaces as revoked rather than
failing quietly.
Routing rules
A channel’s Routing rules decide what an inbound message starts. Rules are evaluated in priority order, top of the list first, and the first match wins — one message starts exactly one thing. A rule can route to an agent, a workflow, or an incident pipeline. All three appear in the rule list, labelled by kind.Rule types
Four kinds, matching the form’s own options:
Channel, keyword, and mention rules are scoped by Slack channel ID in the rule form. A keyword rule
with no channel scope matches account-wide.
Two toggles decide what a route accepts:
- Allow bot posts. Posts from other apps — a Datadog or PagerDuty alert, a deploy notification — are ignored unless a rule explicitly opts in. That opt-in is how you route machine-generated alerts to an investigation agent.
- Default route. One rule can be marked the default: it catches messages that match no other rule, so the bot always has an answer path. A default rule ignores its own matching conditions — mark a keyword rule as the default and its keywords stop applying, so it catches everything that reached it. Only the bot-post setting still applies. An incident-pipeline route cannot be the default.
Rules you cannot edit here
Two kinds of rule appear in the list read-only, each with a chip saying where it comes from:
For these rows the reorder arrows, the enable toggle, and delete are all disabled — editing them here
would be undone by whichever system owns them.
A route to an incident pipeline is not created here. It comes from that incident pipeline’s own Slack
triggers, so the rule form offers Agent and Workflow as targets only. Incident-pipeline routes
show up in the list because they are real routes on this channel, and they are read-only because the
incident pipeline owns them.
Precedence in practice
Agent-spec rules and rules you create in the console are ordered against each other in one list, and a console-created rule usually lands near the top. Rather than reasoning about it, read the real precedence off the channel page: the Routing rules list is sorted by priority, and whatever is nearest the top wins. To change it, use the reorder arrows. The default rule is the exception. It is considered only after every other rule has failed to match, wherever it sits in the list — so a default near the top still loses to any rule below it that matches. Because the first match wins, two agents that both listen in the same Slack channel do not both get the message — the higher rule wins, and the overlap is ambiguous by construction. If two agents must both respond, give them distinct channels or model the fan-out inside one workflow rather than in the routing table.Who the agent is acting for
The first time someone messages the bot, KAOP prompts them in Slack to connect their Slack identity to their KAOP user with a quick sign-in link. Once linked, runs started from their messages are attributed to them rather than to the bot, which is what keeps the audit trail honest. Until a sender links, their messages get a connect prompt instead of a run. Two exceptions, both deliberate: a bot post cannot link an identity, so bot-triggered runs act under the agent’s own principal; and a message routed to an incident pipeline creates an incident regardless, because a human mentioning an outage should not be blocked on their account linkage.What happens when a message matches
1
KAOP reacts to the message
A reaction is added so the sender knows it was picked up. This happens for every kind of
target — unless the rule routes to a disabled agent, in which case nothing happens at all:
no reaction, no reply, and no run. An agent that has stopped answering in Slack is worth
checking for that first.
2
The target is invoked with the message as input
Any preset input on the rule is merged in. An agent target becomes a run recorded with channel
slack. A workflow target starts a workflow, whose agent steps are their own runs. An
incident-pipeline target opens an incident and runs its orchestrator.3
An agent target replies in-thread, live
A threaded reply is posted immediately and updated as the agent streams its progress, so the
thread shows the work happening. The final reply renders the run’s human-readable output.
Only an agent target replies in-thread
This is the single most important behavioural difference between the three target kinds:
Evidence is recorded for every target kind. The run, or the workflow’s step runs, or the
incident’s orchestrator and specialist runs, all land in KAOP with their full evidence trail — so the
operational record is complete even where Slack shows only a reaction. That is the point worth
internalising: silence in the thread is not silence in the platform.
If an agent run fails, the threaded reply says so and links to the run so you can read the full
evidence rather than guessing from a one-line error.
Messages that match nothing
A message that explicitly addresses the bot — a mention or a DM — and matches no rule gets one in-thread reply saying so, rather than silence. It is best-effort and stays quiet in the cases where a reply would be wrong: a bot post that named the bot does not draw a public answer, and a paused, errored, or revoked channel does not post at all.Who answered, and who really answered
Routing decides which agent receives a message. The two diverge as soon as that agent delegates, which is normal for a general-purpose assistant that hands off to a specialist. Every channel reply therefore carries a one-line attribution footer naming the agent that answered and, when it delegated, the agent that handed off — with each run linked. The footer is added by KAOP’s reply path, not written by the agent. A footer the agent authored would be exactly as trustworthy as the paraphrase it exists to make checkable. If you want one run and one bill instead of two, write a rule that routes straight to the specialist.Next steps
Your own Slack app
Create the app, connect it for chat or the Slack MCP, and manage its tokens.
Runs & evidence
Messages from a channel produce ordinary runs — here is what they record.
Incident management & troubleshooting
Incident pipelines, and the Slack triggers that own their channel routes.
Roles & permissions
Who can connect a channel and manage its routing.