Testing shared channels in Slack

Get comfortable with the functionality of shared channels with these simple tests


In order to test shared channels you will need access to a sandbox account for your paid Slack instance (e.g., Standard, Plus or Enterprise Grid plans). If you need a sandbox account, work with your Customer Success manager to set one up.

It’s easiest to have two people run these tests together—one acting as the admin of a sandbox account, and one acting as the admin of your regular account. We will refer to the production account as Workspace A and the sandbox as Workspace B.

How to enable shared channels

If it’s the first time your organization is enabling shared channels, it’s a good idea for Slack admins to practice using the feature before connecting channels in your production Slack instance. Run through these test cases to learn the expected workflow:


Reviewing and testing apps in shared channels should be done prior to introducing any app into the shared channels in your production workspace. For this exercise, let’s assume apps are installed in Workspace A.

Before using apps in shared channels, consider the following:

Data security

Apps that pull data into a Slack channel might be appropriate for internal use but inappropriate for use in a shared environment. Be sure to review your apps to understand if there is the possibility of accidentally leaking sensitive information into a shared channel.

  • Ex: Suppose a custom Jira integration posts ticket updates into a channel. If there’s a chance that updates could contain private information, this app should not be used in a shared channel.

File-sharing apps frequently offer the ability to grant access rights to all members of a channel. Be sure this is appropriate for your use case. Are you comfortable with members of Workspace A granting file permissions to Workspace B members?

  • Ex: A Google Drive integration could allow users to grant access permissions to documents

Third-party access and licensing

Many popular Slack apps are built by software companies to provide another entry point to their service. In many cases, they require a license to access the full suite of functionality available in the app. Be sure to understand whether the service associated with the app can be used by all the shared channel members. If not, does it still provide a useful service?

  • Ex: The Trello app might be of little use to members of the shared channel if one organization does not have access to Trello


If an app is interacted with (e.g., message action, slash command) by a Workspace A member, what is the experience for members of Workspace B?

Can Workspace B members interact with Workspace A apps? Although slash commands and message actions are restricted to members who belong to the workspace the app is installed in, some interactive elements will remain accessible.

  • Interactive Message Buttons: If an app posts a message with an interactive message button, anyone in that channel can click the button. How does a Sandbox A app respond if the request is from a Sandbox B member?
  • @mentions: Some apps are designed to be interacted with when a member directly @mentions a bot. If a bot is invited to your shared channel, what happens when a Workspace B member sends it a DM?

At a minimum before enabling a shared channel, be sure to check whether any sensitive information could be exposed by your apps. Apps in the Slack App Directory should be designed for use with multiple organizations, but internal app developers might not have designed for this use case. If possible, have the app developer review the code and confirm that the app can be used in a public setting.

    Was this resource useful?



    Thanks so much for your feedback!

    Got it!

    Thanks for your feedback.

    Oops! We're having trouble. Please try again later!