Developers guide to Slack Shared Channels
Introduction
From time to time, I look at Slack platform API docs in order to find something new we can implement in the Raidboss App. For sure, we are also subscribed to the Slack API newsletter.
One day I noticed new API articles about shared channels and Slack Enterprise Grid.
After a brief research, I have concluded that we missed this feature in the initial version of our app.
Ok, all done!
After reading Apps in shared channels and Building apps in Enterprise Grid, it was clear that if our app supports global IDs and detects the context of the workspace appropriately, we will be safe. Users from other workspaces cannot interact with the app where it’s not installed. Keeping this in mind we reviewed our source code and forgot these long articles, assuming we were all done.
You can’t imagine how surprised we were a few months later when we got a series of weird alerts from our logging tool. Literally, it looked like there was a user but the workspace was unknown. First, we thought it was a mistake in our logging code and added more logs.
But such cases became more and more frequent. Secondly, we started to think the Slack platform was going crazy or had been hacked, for example. But after thorough digesting of log entries, we finally got a clue — this is an Enterprise Grid setup. How is it possible to get activity from foreign workspaces even if they are part of the same Grid? Each workspace has to install its own app. The right answer is by using shared channels.
As stated in the documentation, there is a simple way to support shared channels — abandon users who are not from the workspace where your app is installed.
However, we are not looking for simple solutions and decided to go deeper and read on to understand what is the full-fledged way of integration. And this is where our integration journey begins.
Target design
We have read all the related documents twice more, trying to apply the instructions to our situation and find a suitable solution. Honestly, it was not very helpful until we started to experiment.
One of the key features of the Raidboss is a challenge with assigned rewards. Game Master can start a challenge in any channel via shortcut or slash command.
Members of that channel can accept the challenge and notify the author upon completion.
The author receives a completion request and approves it or rejects it providing comments.
Logically there are several possible scenarios. Let’s take a look at the simple case with a shared channel between two workspaces. The logic remains the same if there are more workspaces.
Scenario A: Raidboss app is installed only on one of the workspaces.
It looks like a simple case. We can treat users of the second workspace like regular users of the first workspace within Raidboss and provide the same experience. This means any member of the shared channel is able to participate in a challenge, earn rewards, and be a part of the single leaderboard.
Scenario B: Raidboss app is installed on both workspaces.
Let’s take the same example but consider when a second workspace installs the Raidboss app a bit later.
Game Master of the `Cats` workspace creates a new challenge within the shared channel.
Members of both workspaces are able to accept, earn rewards, and be a part of the leaderboard. Wait. Which leaderboard? We have 2 separate leaderboards for each of the workspaces. The correct answer — it depends on who has started the challenge.
If the Game Master of `Cats` initiated it, we designate all acceptances and rewards for `Cats` workspace. And the opposite occurs if the Game Master of `Dogs` workspace was the author.
As you can see, this also implies we count the same user two times: one in the context of `Dogs` and the second in the context of `Cats`. And such a user has two separate leaderboards.
Also, it’s worth mentioning that it’s impossible to prepare exclusively for scenario A or B.
Workspace admins can install, uninstall, and install your app again transitioning between A and B, back and forth.
Implementation
Let’s take a look at the technical details of those scenarios.
From the Slack platform’s perspective, it means the entire chain of activities (accept, complete/reject, get a reward) related to the challenge should be dynamically connected to one of the workspaces based on the authorship. But Slack platform does not know anything about challenges, which are just abstract messages with text and buttons, and authorship.
The platform sends events and triggers interaction callbacks specifying the context of the workspace where it happened. And we could not rely on it anymore — this is where we received unknown workspaces for scenario A. And this is where we have to determine the workspace by authorship of the challenge for scenario B. It means we need to redo the entire app workflow related to the detection of the workspace context and carry out the challenge authorship through all the steps.
Continuing our experiments, we have figured out some interesting details.
It’s not documented, but the behavior of Slack platform in relation to the shared channels can be one of two types:
- Team ID (or workspace ID) is adjusted by the Slack platform. If the interaction initiated within the `Dogs` workspace and a user from `Cats` interacts with your app (e.g. via interactive message) then you will still receive a Team ID of `Dogs`.
- Team ID is untouched but there is a separate property called `app_installed_team_id` in Slack’s payload. It contains a Team ID of the workspace where interaction has been started (meaning it definitely has the app installed).
An important detail is that the Slack platform keeps the context of the workspace for the chain of interactions.
This detail saves us a lot of time because instead of replacing all the code related to workspace detection with an authorship based approach (or another relation-based approach), we simply can look at the `app_installed_team_id` property or, if it’s empty, at the Team ID.
Further steps
It’s worth mentioning that it’s still impossible to provide a full experience of any app for users from workspaces other than an app installation workspace. You cannot serve slash commands, shortcuts, actions, and the majority of the events. It forces you to review the entire implementation to ensure the app is still useful for such a user.
By implementing the steps above we easily allowed any users to accept challenges and get rewards. But in addition, we paid extra attention to how the user accesses other crucial parts of the app functionality.
The options are:
- App home page (yep, once your app has communicated with the foreign user, this user will see your app in their own workspace);
- Direct messages with your app (similar to the previous point);
- Response to interactions (e.g., once the challenge is completed we provide interactive buttons within the same notification to access leaderboard or shop).
Our team continues to explore how to improve the UX of the app to keep the same level of usefulness and even more, support new cases like those based on common interaction of multiple workspaces within the shared channel.
Subscribe to our blog to get updates on Raidboss app features and our way of implementation of Slack platform capabilities.
