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 subscriptions). If you need a sandbox account, work with your Customer Success Manager to set one up.
It’s easiest to get two people to 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 one as Workspace B.
How to enable shared channels
If it’s the first time your organisation is enabling shared channels, it’s a good idea for Slack admins to practise using the feature before connecting channels in your production Slack instance. Run through these test cases to learn the expected workflow:
All apps should be reviewed and tested before introducing them 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:
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 check whether there is a possibility that sensitive information could accidentally be leaked into a shared channel.
- Example: 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?
- Example: 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 licence 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?
- Example: The Trello app might be of little use to members of the shared channel if one organisation does not have access to Trello.
If a Workspace A member interacts with an app (e.g. message action, slash command), how will members of Workspace B experience this?
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 Workspace A app respond if the request is from a Workspace 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, make 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 organisations but internal app developers might not have planned 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.