Slack Enterprise Grid allows large organizations to collaborate across many workspaces. While many apps, integrations, and bots will work as expected on Enterprise, there are enough new behaviors, conditions, nuances, and opportunities to warrant reviewing your app for full compatibility.
Read on if:
Really, if you're using any aspect of the platform at all and want to support Enterprise Grid β this guide is for you.
Enterprise Grid is a "network" of two or more Slack workspace instances. Each Slack workspace has its own ID, its own directory of members, its own channels, conversations, files, and zeitgeist. For the most part, each workspace behaves and acts functions as you're used to.
The biggest delta for your app, integration, bot, or mind to handle is that some channels and conversations can be shared between multiple workspaces within the same Enterprise organization.
As with typical Slack workspaces, workspaces on an Enterprise Grid have their very own application installations.
This guide may be your first introduction to the following terms:
U
or W
representing a user across all workspaces within an Enterprise Grid.U
. Also known as a local user ID.team_id
, it means the ID for a workspace.If your app or integration is never installed on an enterprise organization's workspace, you won't encounter any of the particularities detailed in this document.
However, if you have the good fortune to be installed by one or more Enterprise Grid workspaces, or a workspace you're already installed on becomes part of an enterprise organization's workspace:
W
.You never know when a workspace on Enterprise Grid will install your app. Without making a few tweaks, your new users may notice these (and other) quirks in your app's behavior.
Different kinds of integrations with Slack will need to consider Enterprise Grid in different ways. API responses may differ in Enterprise Grid workspaces, and your app will need logic to deal with things like semi-duplicate messages when it's installed on multiple workspaces within the same Enterprise Grid.
But no matter which way you've built your app, the best thing you can do for yourself is use our migration.exchange
method to update all records you have for an existing workspace with those from an Enterprise Grid. Then you won't need to worry about a "translation layer" or maintaining two IDs for a single user.
API | Support strategies |
---|---|
All Slack apps |
|
RTM |
|
Events API |
|
Web API |
|
Incoming webhooks |
|
Slash commands |
|
Interactive components |
|
To walk through all the steps of supporting Enterprise Grid in your apps, check out this guide.
A shared channel is a bridge between teams needing to work together. Instead of endless email threads or sidecar Slack workspaces, teams can use shared channels to connect, chat, share files, and use apps the same way they communicate with their more immediate colleagues.
Maybe you're just learning about shared channels or maybe it's years from when this documentation was written. Hello, time traveler. In either case, let's rewind to life before shared channels to understand how they can make your working life simpler and more productive:
Before, when messaging was more limited, what our feline friends were saying and doing on the project that impacted these playful pups was a mystery. When the two teams tried to communicate it was disconnected, disparate, and duplicative.
This is now solved with shared channels. Now the project channel #projectM
exists in each team's workspace (Catnip Inc. and Woof Inc., respectively).
To learn even more about how shared channels work, check out our resources on Apps for shared channels
There are two types of shared channels, each with different uses:
Slack Connect channels allow up to 20 organizations to come together in a single channel (e.g. Catnip, Inc. and Woof Inc. from the examples above).
Multi-workspace shared channels are shared between multiple workspaces within the same organization's Slack instance. For example, the #treats
channel is shared in Woof Inc's, Marketing, Engineering, and Social workspaces. It exists in all three places, within Woof Inc.'s single Enterprise Grid instance.
In most cases, an Enterprise Grid is formed by combining multiple independent Slack workspaces together. During this period of time where data is migrated and made compatible with Grid's organization structures, Web API calls, RTM API connections, Events API, and other platform interactions may be unavailable, both for users and your applications.
On the Web API, you may encounter the team_added_to_org
error during this time.
Migration time varies depending team-to-team and organization-to-organization. Practice an exponential backoff strategy when encountering errors to help manage these periods by attempting connections at incrementally increasing rates: 1 second to 3 seconds to 10 seconds to 30 seconds to 1 minute, and so on.
To best plan for migrations, subscribe to grid-related app events as part of the Events API. Using these events, your app can pause and resume activity as appropriate.
When migration is complete, use migration.exchange
to receive global user IDs for any of your stored local user IDs and then turn off the translation layer if you haven't already.
You'll find user objects on Enterprise Grid workspaces now have an enterprise_user
attribute, containing a hash of additional context about the user in the larger Enterprise Grid organization.
You'll find:
id
- this user's ID, which might start with U
or W
enterprise_id
- the unique ID for this particular Enterprise Grid organizationenterprise_name
- the name of this umbrella organizationis_admin
- a boolean value indicating whether this user administers this Enterpriseis_owner
- a boolean value indicating whether this user is the owner of this Enterpriseteams
- an array of team (workspace) IDs within the containing enterprise organization that this user belongs toWithin an Enterprise Grid, all users have a single, global ID beginning with either the letter W
or U
.
We'll automatically convert references to a user's previous, pre-Enterprise-migration ID to their singular Enterprise ID. This allows your app to remain backwards compatible for users you've identified on a workspace before the days of Enterprise Grid.
Users created after a workspace became part of an Enterprise have no pre-Enterprise-migration ID.
Global IDs may begin with U
or W
. Historically, global IDs always started with W
but that is no longer true. Newly created users will have a U
user ID and that will be their global ID and they'll have no local user ID.
Use migration.exchange
to gather all the divergent user IDs in a workspace and update your records. A single source of truth for user IDs in your systems will benefit you greatly and reduce complexity for you in the long run.
Slack Apps can turn on a translation layer in their app settings that will display "local" historical user IDs beginning with U
for users that existing prior to an Enterprise Grid migration for a workspace the app was already installed on. It also lets you use these classic user IDs within a migrated workspace. It's meant to be used for a short while.
We strongly recommend you turn this translation layer off after using migration.exchange
and going all-in with global user IDs, regardless of which letter they start with.
As with all Slack apps, installation and ownership of apps is on a workspace-basis. Single-workspace apps, as their name implies, are locked to a single workspace and cannot be installed across an Enterprise Grid.
Find out more in our single-workspace apps documentation.
Building properly for shared channels or Enterprise Grid requires experiencing the unique constraints and opportunities yourself.
If you don't already have access to an Enterprise Grid of workspaces, please complete the form below to request a sandbox. We'll get back to you as soon as possible.
To learn more about sandboxes and how to get started testing, click here.