Shared Slack Connect channels with customers: whose messages are they?

Who controls the messages in a shared channel?#

In a Slack Connect channel, each connected organization administers its side through its own workspace settings, such as retention, exports and admin access. Slack documents how ownership, retention and exports work for Slack Connect, and the details vary by plan and can differ from internal channels, so check the current documentation before relying on any export.

Control, in this sense, is administrative. It answers whether your admins can retain, search or export the conversation. It does not answer whether you may give the content to a third party for a new purpose, which depends on contracts, confidentiality duties and privacy law.

Why holding a copy is not the right to license it#

Holding a copy is not the right to license it because the messages carry obligations that travel with them. A customer engineer who posts a stack trace, describes an outage or asks about their architecture is sharing their company's confidential information under your relationship, usually covered by the confidentiality clause in your MSA or an NDA.

Those messages also contain personal data about the customer's staff: names, profile details, working patterns and sometimes opinions about colleagues. Privacy laws may apply to that information depending on where the people are, and nothing they were told when joining the channel is likely to have mentioned AI training.

This is general information, not legal advice. Whether a particular use is permitted turns on your contracts and the laws that apply, which counsel should assess deal by deal.

Which messages can be considered for a license?#

Messages can be sorted by who wrote them and where, and each category has a sensible default. The table is a starting point for counsel and the CTO, not a final rule.

Most of the value usually sits in the first row. Internal engineering and support channels capture how your team diagnoses and fixes problems, and they involve far fewer outside rights than anything shared.

Why are shared-channel threads hard to split?#

Shared-channel threads are hard to split because the value sits in the exchange, not in either side alone. Your engineer's reply about a failing integration is useful precisely because it answers a real customer question, and removing the question usually strips the answer of meaning.

Rewriting or summarizing the customer's side does not solve the problem, since a summary is still derived from their content. In practice, teams either exclude shared-channel threads entirely or seek a customer's permission for a defined set of threads, then remove personal and identifying details from both sides.

Watch for leakage into internal channels too. Engineers often paste customer messages into internal threads, Jira issues or incident documents, so customer content can surface in records that look internal.

How to find shared channels before any export#

Finding shared channels starts with an inventory, not an export. Workspace admins can usually list channels connected to external organizations and identify users who belong to other companies; the exact method depends on your plan, so confirm it in the admin documentation.

Plan limits shape what any later export can reach. Slack's export help says Workspace Owners and Admins on all plans can export messages and file links from public channels, while exports that also cover private channels and direct messages are available only on Business+ and Enterprise plans, and Owners must apply to use them. Do not assume access to shared-channel history until that is confirmed.

Keep the inventory with the rest of your data map. It will be needed again for retention reviews, legal holds and any later request from a customer to include or remove its threads.

• 1List every channel with its connected organizations, purpose and active date range.
• 2Flag direct messages and group messages that include external users.
• 3Identify internal channels where customer messages are often pasted, such as escalation or incident channels.
• 4Record which customers have contracts with stricter confidentiality or no-AI-use clauses.
• 5Mark each channel include, exclude or needs permission, with the reason.

What should customer agreements say about shared channels going forward?#

Customer agreements should say plainly how shared-channel communications are treated, because most were drafted before shared workspaces became a normal support channel. Clear language now avoids arguing later about whether a message was customer data, confidential information or ordinary correspondence.

Changes like these generally apply going forward, and enterprise customers will negotiate them. They make future decisions easier, but they do not convert years of existing shared-channel history into licensable material.

Illustrative: a DevOps tooling company with customer channels#

Illustrative: a fictional DevOps tooling company runs Slack Connect channels with its largest customers for onboarding and incident support, alongside internal engineering and support channels. Leadership wants to license its internal engineering discussions as part of a broader package.

The general counsel and CTO build a channel inventory and exclude every Slack Connect channel and every external direct message. In internal escalation channels, messages that quote customers are removed or redacted, and customer names and hostnames are replaced throughout.

The resulting package is smaller than the full workspace but clean. One customer later offers to let selected incident threads be included, and that request is handled as a separate agreement with its own scope and review.

How SourceX handles shared channels#

SourceX handles shared channels in the Rights step of the SourceX five-step transaction by classifying conversations as internal, shared or external direct messages before anything is exported. Messages from external participants are excluded by default.

During Preparation, quoted customer content is removed from internal channels, and the SourceX Evidence Packet lists the channels and message types excluded, with the reason for each. The company approves the final scope before Delivery.