OpenClaw Slack Enterprise Grid

An Enterprise Grid organisation is many workspaces that share users and administration, and a bot installed once at the organisation level can hear from all of them. That changes what a channel ID means, because the same ID can exist in two workspaces, so almost every rule on this page comes down to one idea: qualify the key with the workspace. Here is the install, the manifests, the key formats, what an enterprise account supports, and what fails closed.

Installing org-wide

• One Slack account can receive messages and interactions from every workspace covered by an org-wide installation, over direct Socket Mode or HTTP request URLs, with relay mode unsupported for enterprise accounts; the two least-privilege manifests enable the message, mention, reaction, pin, channel-created and channel-renamed event paths, immediate replies, listener-owned status reactions, interactivity for Block Kit actions and modal submissions, and the single slash command.
• Both manifests set the org deploy flag, declare a smaller bot scope set than the workspace manifest, mentions, history and read for channels, groups, DMs and group DMs, chat write, commands, files read and write, pins read, reactions read and write and users read, and subscribe to the mention, channel-created, channel-rename, four message, membership, pin and reaction events; the HTTP variant adds the interactivity and event request URLs.
• An Org Admin or Org Owner approves the app, installs it at the organisation level and chooses the covered workspaces, and you confirm the app is available in every intended workspace before starting OpenClaw; Socket Mode then needs an app-level token with the connections write scope and the bot token from the org installation, while HTTP needs the bot token and the signing secret after Slack verifies the request URL.
• The example enterprise config enables the channel, references both secrets from the environment, keeps the single slash command, opens DMs with a wildcard allowlist, sets the channel policy to allowlist and lists channels by their qualified key made of the team prefix, the workspace ID, the channel prefix and the channel ID, where the workspace ID is copied from the Slack web client URL and paired with the channel ID in every qualified policy key.

Install once at the organization level, then set workspace-qualified policy keys.

Detection, support, routing

At startup OpenClaw calls the auth test to detect whether the token belongs to a workspace installation or an org-wide one, so no installation-mode setting exists; Slack stays the source of truth for which workspaces have granted the installation, and OpenClaw applies the configured channel, user, DM and mention policies to each delivered event. Enterprise installs reject bot-authored message and mention events by default, and the allow-bots setting on the account or channel admits them under the same loop-prevention rules as workspace installs, using the retained user and bot IDs from the auth test. Enterprise support covers direct Socket Mode or HTTP message, mention, membership, reaction, pin, channel-created, channel-renamed, Block Kit action, modal and configured shortcut and slash-command payloads plus workspace-qualified outbound messages and presence polling, with shortcuts added to the manifest and accepted by callback ID; relay mode, channel-ID-change events, App Home, the Agent and Assistant lifecycle events, configured ACP bindings and runtime current-conversation bindings stay unavailable, while static route bindings work when a binding names a team ID or uses a qualified channel or user peer. Native approvals from a delivered workspace-qualified turn are supported through the same listener-owned interaction path, all action groups work with their gates and scopes still applying, and inbound membership, reaction, pin and channel notifications use validated workspace-scoped routing, with acknowledgement, typing and status reactions needing the reactions write scope. Destinations are recorded as qualified channel or user keys, current-conversation actions inherit that workspace, heartbeat owner routing can resolve a bare user ID by verifying membership against the bot's installed workspaces and picking one shared workspace while keeping an explicit qualified target, and other detached or proactive calls must provide a qualified target because bare IDs can be reused across workspaces and fail closed; actions without a destination, such as member info and emoji list, need trusted current conversation context. Immediate replies reuse the standard delivery behaviour only while the validated listener-owned client remains in the active turn, and the in-memory send queue and thread-participation records are partitioned by the event's workspace without the client ever being serialised or persisted.

The key rules

• Enterprise channel policy keys must be qualified or the wildcard, the group-DM channel list requires the qualified form and rejects the wildcard, a delivered event never falls back from its qualified identity to a bare channel ID, workspace installations keep raw stable channel IDs and the channel prefix, and the slack, group and mpim channel prefixes fail startup.
• User entries in the allowlist, the reaction allowlist and per-channel users accept raw stable user IDs, the slack or user prefixes, the qualified team and user form, or the wildcard, where unqualified entries compare only the user ID and can match an org-wide user in any workspace while qualified entries compare both; tools-by-sender keys accept raw IDs, the id prefix, the channel-slack prefix or the wildcard, and names, slugs, display names and email addresses fail startup, as do lowercase or short lookalike IDs, since IDs must use Slack's canonical uppercase prefix and body.
• Enterprise accounts cannot enable dangerous name matching, may set the global mention-pattern mode, and must qualify the allow-in and deny-in mention-pattern entries because bare channel IDs fail startup; each accepted workspace gets separate routing, session, transcript, dedupe, history and cache identity even when IDs overlap, only ordinary user messages and user-authored file shares are supported in the message stream with other subtypes rejected before authorisation, DMs support the same disabled, open, allowlist and pairing policies, pairing approvals are stored per workspace and user and apply only to that workspace, and an account allowlist entry can omit the workspace for an org-wide user or include it to limit access to one workspace.

OpenClaw on Slack is the channel post this install extends, and OpenClaw Slack access control the workspace-level rules these qualified keys are built on.

Why bare IDs fail closed

Two workspaces in one organisation can hand out the same channel ID, so a proactive send addressed to a bare ID could land in the wrong division of the company; failing closed on unqualified targets is the cheapest way to make that impossible. OpenClaw bot loop protection covers the loop rules that bot-authored events fall under once admitted, and OpenClaw channel routing how a qualified peer becomes a static agent binding.

On Diali

Slack is one of the channels Diali connects from the dashboard, with the runtime config generated and replaced at each release, so the qualified keys and guards described here are the vocabulary behind that connection rather than a file you maintain. Slack on Diali describes the channel on Diali and Diali security the boundary every connected channel shares.

• One install, every workspace; keys carry the workspace ID.
• The auth test decides the mode; no setting needed.
• Bare IDs on detached sends fail closed by design.