Why anonymity gets ambiguous in Connect
Slack Connect is the product feature that lets a channel be shared between two or more Slack workspaces. A channel created in your workspace can be invited to from another company's workspace; users from both workspaces show up in the same channel, with the same threads, the same reactions, and — usually — the same shared message history.
The feature is enormously useful for cross-company collaboration. It is also the case that the moment a channel becomes a Connect channel, the anonymity guarantees of any bot operating in that channel become substantially more complicated to reason about.
This is not a HushAsk-specific problem. It is a property of how Slack Connect handles permissions, app installs, and audit logs across workspace boundaries. But because most teams adopting an anonymous feedback tool reach a point where they want to use it in a Connect channel — to gather anonymous input from a partner's team, or to run an anonymous question session with an external advisor — it is worth being precise about what does and does not work.
The short version: anonymous bots can operate in Connect channels, but the anonymity model changes in three concrete ways. The IC sending the anonymous message should know about those changes before sending. Most "anonymous in Slack" tools do not talk about them.
Three places anonymity leaks
App installation scope. When a Slack app is installed in a workspace, it has access to the events Slack pushes to it for that workspace's channels. In a Connect channel shared between workspace A and workspace B, each workspace's installed apps see messages in the channel — but each app sees them as members of its own installing workspace, not as members of the unified channel. This matters because most anonymous bots use the sending workspace's user identifier to compute the anonymization hash. If the app is installed in only one of the two workspaces, users from the other workspace either cannot use the bot at all, or use it with a different identity model than they expect.
Audit log scope. Slack Enterprise Grid workspaces have audit logs that record bot DM activity. In a non-Connect context, that audit log lives within the sending user's workspace. In a Connect channel, Slack maintains audit-log entries on both ends — meaning a message a user sends in a shared channel can show up in two separate audit logs, owned by two different organizations, each with its own retention policy and its own administrator with access to it. The anonymity claim "your admin cannot see this" implicitly assumes a single admin and a single audit log. In Connect, there are two of each.
Mention metadata. When a user is mentioned by name in a Connect channel — even in passing, even in a reply thread — that mention is rendered as a user identity link in both workspaces' clients. If an anonymous message in a Connect channel references a specific person by @mention, or quotes a previous named message with metadata intact, the anonymity of the sender does not protect the named person from being a data point in both workspaces' message stores.
None of these leaks are about the cryptographic anonymization of the sender's identifier — that part is the same. The leaks are at the boundary where the message travels between two workspaces, each with their own permissions, audit logs, and admin surface.
What HushAsk does and doesn't do
HushAsk is designed for the single-workspace case. The Slack user identifier is replaced with a 64-character SHA-256 hash at send time. On Free, Pro, and Business+ Slack plans there is no path back to the original sender. (On Slack Enterprise Grid plans, Slack's own audit log records bot DM activity as a separate layer — a constraint HushAsk cannot suppress.)
In a Connect channel context, three things are still true. The sender's identifier is still hashed at send time. The hash is still cryptographic — not a lookup-table mapping. The leader replying anonymously through the bot still has the names stripped on the reply path.
Three things are not the same. First, the bot must be installed in the workspace whose users will use it — Connect channel membership alone is not sufficient. Second, the audit log surface on the receiving side of a Connect channel is independent of the sending side's audit log — meaning the receiving workspace's admin, if on Enterprise Grid, can see bot DM metadata that the sending workspace's admin cannot. Third, any @mention or named-quote in an anonymous message will still render as identity-linked content in both workspaces' clients, regardless of the anonymization of the sender.
HushAsk does not solve these issues. They are properties of how Slack Connect handles cross-workspace permissions and audit logs, not properties of any specific bot's anonymization model. The practical implication is that "anonymous feedback in a Connect channel" requires the team to know which workspace they are sending from, which workspaces have which admin surface, and whether the message contains named references that travel through both workspaces' audit logs.
When to use Connect for anonymous flows
Three patterns work in practice.
Use Connect for anonymous flows when the cross-workspace context is the point. A vendor-partner relationship where you genuinely want anonymous feedback from the partner team about your team's responsiveness, with the explicit understanding that both organizations have admin surface on the channel. The transparency about the dual-audit-log situation is what makes the channel honest.
Do not use Connect for anonymous flows when the IC sending the message would not send it if they knew the receiving workspace had separate admin surface. The most common version of this is using a Connect channel for anonymous feedback about a relationship with the external party — that is the conversation where the asymmetric admin surface matters most, and where the anonymous channel is least suited.
The middle case: use a private DM with the bot — outside of any Connect channel — for any cross-workspace anonymous flow where the IC would be uncomfortable with the receiving workspace's admin having any visibility. The DM model collapses back to the single-workspace case and the standard anonymity guarantees hold.
The general rule: anonymous tools in Slack operate on a single workspace's identity and audit-log model. Connect channels span multiple workspaces, each with their own model. The two compose, but the composition has edges. The IC should know the edges before sending. The leader running the channel should know the edges before promising anonymity. Most "anonymous in Slack" tools do not explain this distinction. The trust that anonymity builds depends on getting the explanation right before the first message is sent, not after.