The essential guide to right-sizing your Slack Grid

A step-by-step approach to consolidating workspaces for maximum collaboration effectiveness

Photo by Karolina Grabowska via Pexels

So your organization has upgraded to Slack Enterprise Grid and you’re in charge of ensuring that it meets the needs of all the teams that will rely on it for daily communication and collaboration. As your organization has grown, different teams may have set up their own Slack workspaces. One of the great benefits of upgrading to Slack Enterprise Grid is the ability to have unlimited workspaces inside a centralized management environment. But this Grid capability can also become a problem if the number of workspaces creates governance and collaboration issues.

There is no “right” way to design a Slack Grid org in terms of the number of workspaces, but a good strategy to use is the “less is more” principle. Slack has identified some best practices for finding the right balance of workspaces in Grid.

Source: Slack Technologies, LLC, a Salesforce company

While these concepts provide useful general guidelines, most organizations I work with need a more prescriptive method for assessing what is best for their Grid environment. Keep reading to learn how to make sure you have a workspace structure in Grid that meets your needs, when it makes sense to streamline your Grid through workspace consolidation, and what you need to know about the consolidation process.

Are there specific reasons to have multiple workspaces in Grid?

It could be argued that the number of workspaces in Slack Grid doesn’t matter since anybody in the Grid org is able to direct message regardless of the workspace they are in, and since it’s easy to create shared channels between workspaces. While these points are correct, they don’t account for the increased administrative overhead, added difficulty in applying standards in the usage of Slack, and decreased transparency and searchability as information gets compartmentalized in workspaces.

There should be a compelling reason for each workspace in the Grid org ; here are some common scenarios that could justify a multi-workspace approach:

• Organizations with highly autonomous business units (e.g., media company with different studios/brands)—reduces channel sprawl in each workspace and provides a more intentional experience for users based on their business.
• Functional areas that have highly restricted content (e.g., board of directors, M&A, legal investigations)—enables information barriers through restricted workspace access; workspaces can also be hidden from Grid members.
• Communications that require additional governance (e.g., Slack Connect channels, Slack for customer communities or events)—facilitates implementation and oversight of specific policies related to Slack usage; more restrictive policies or information barriers can be set up and enforced in those workspaces.

When does it make sense to consolidate workspaces?

If your Grid org has come to the point where you need to cull some of the workspaces, how can you determine which ones are good candidates for consolidation? There are four good indicators for recognizing an opportunity to right-size your org:

• Decreasing activity — An argument could be made that this is an opportunity for workspace deletion, but all the channel history will be lost. By moving the channel contents into another (more active) workspace, you will not only retain the information in those channels but also help reinvigorate activity by moving the members into a workspace that has frequent communications and collaboration.
• Lots of shared channels between workspaces — Creating multi-workspace channels can be useful, keeping users from having to continually switch between workspaces when collaborating with people who primarily work in different workspaces inside a Grid org. But if there are many shared channels between specific workspaces, it can be an indicator that they would benefit from consolidation.
• Organizational (re)alignment — Whether it’s based on changes to organizational structure or if it’s just to help bring together groups that roll up under a common leader, the consolidation of different workspaces inside a Grid org can make sense. Whatever the initial rationale for having separate workspaces, they should be reviewed on a periodic basis to determine if it still makes sense from the perspectives of communication, collaboration, and teamwork.
• Acquired companies using Slack — When an acquisition happens, if that organization is already using Slack, then it makes sense to migrate their workspace into your Slack Grid org. Once it has been migrated, it should then be considered for consolidation with an existing workspace based on how the acquired organization is going to be structured within your organization. If it makes sense to continue with its own workspace, then there is still an opportunity to use multi-workspace channels to remove redundancies and create a sense of community with others in your organization — no need to have separate #caturday channels.

Determining the best direction for a consolidation

Consolidation is all about combining workspaces, which is typically achieved by moving one workspace into another one. If a consolidation is determined to be appropriate, careful consideration needs to be given as to which workspace will be moved and ultimately archived. The consolidation process is highly manual, so it’s important to determine which workspace will require the least amount of effort to move based on the following workspace characteristics:

• Number of active users
• Total number of channels
• Number of archived channels
• Number of Slack Connect and Grid-shared workspace channels
• Number of installed Slack applications (third-party and internal/custom)
• Number of webhook integrations

The Slack Grid org owner or admin can run reports for workspaces in the Grid environment, which will allow for comparison of the size and complexity of each workspace’s current setup, enabling a decision on a consolidation approach that will be the most efficient.

Let’s consider this comparison between two workspaces:

Workspace usage comparison

Size really matters when doing the actual work of consolidation — you want to move the smaller workspace(s) into the larger one to minimize the amount of effort required. Looking at these two workspaces, it will clearly require less work to move workspace A into workspace B, instead of the other way around. However, your scenario might not be as obvious as this example, so run through the comparison in the following order:

1. The primary consideration should be based on the number of channels that will need to be moved. If the total number is relatively close, then compare the number of archived channels, since these require extra effort to move.
2. The next consideration should be the number of Slack Connect channels, as these have unique challenges related to consolidations (more on this later).
3. When there isn’t a clear difference in the number of channels between the workspaces, then compare the number of apps and webhooks as there is a lot of manual work required to set them up in the post-consolidation workspace.
4. Finally, if you still aren’t seeing a meaningful difference between the workspaces, then compare the number of active users as the tiebreaker to minimize the amount of user preparation required for a consolidation.

Making it happen

Of course, determining whether it makes sense to consolidate specific workspaces should be discussed and agreed to by both the moving and receiving workspace owners prior to doing anything. One important area of discussion is to compare any workspace policy differences for settings that aren’t being enforced at the Grid-level. Once there is agreement and your Grid org team is ready to get started with the consolidation process, then you can dig into preparing everyone for it to happen.

First, make sure to give everyone involved (including the Slack users being moved) enough time to prepare for what’s coming. It is possible to do this on short notice, but I would recommend allotting at least one month for the entire process to plan, prepare users, and consolidate. And in the situation where one of the workspaces exists outside your Grid org, you may need to build in some extra time since it will require a two-step process — you will need to migrate the workspace into the Grid prior to doing the consolidation work.

When it comes to actually doing the work, here are some important things to understand about consolidating workspaces in Grid:

• Add users from the workspace being moved to the workspace that they are moving into before doing anything else.
  → Do not remove anyone from the workspace being moved until you are ready to archive/delete it.
• Grid owners and admins have a channel mover tool available to them, but there are certain work-arounds required for archived channels and the designated general channel (if there is a desire to include it as part of the consolidation).
  → For moving private channels, you will need a detailed channels export from the owner of the workspace being moved so that you have access to the channel names and IDs.
  → Depending on the number of channels that are being moved — especially if there are a large number of archived channels — you may want to consider a programmatic approach to moving channels using the Slack API.
• Multi-workspace channels that exist between the two workspaces only require removing these channels from the workspace being moved. Any multi-workspace channels between the workspace being moved and another workspace in the Grid org will need to be added to the receiving workspace and then removed from the workspace being moved.
• Slack Connect channels are especially tricky to deal with:
  → If the Slack Connect channel was created by the third-party, your users will need to be re-invited to it and then they can add it to the receiving workspace. These channels can then be disconnected from the workspace being moved.
  → If the Slack Connect channel was created by a user in the workspace being moved, it will have to be disconnected and moved to the receiving workspace as a historical reference only; it cannot be reconnected to the external workspaces after being moved, and a new Slack Connect channel will have to be created.
• Apps, integrations, and workflows will all have to be reconfigured in the receiving workspace by your users.

What about consolidating non-Grid workspaces?

If the previous details sound complicated, then brace yourself, as the approach for doing this outside Grid requires custom code. Even more complex is moving users and information out of a Grid environment for consolidation into a non-Grid workspace, which we have seen on occasion when a company is being divested and has been acquired, and all three entities use Slack.

What’s your Slack situation?

Let me quickly recap what we have covered:

• Consider when it makes sense to have multiple workspaces in Slack Grid and when collaboration would be improved by consolidating workspaces.
• Determine the easiest path for the consolidation process.
• Get buy-in from the admin teams in the workspaces being considered for consolidation and give them sufficient time to prepare themselves and their users for what will happen (and when).
• Make sure the admins understand the key details I have included here about consolidating workspaces.

While consolidating workspaces in Slack may feel daunting, any situation involving change can be successfully completed through best practices, a methodical approach, and clear communication with your users. Slalom has experience working with every scenario I have described, and we know how to efficiently manage every nuance involved with planning for and executing Slack consolidations, including how to prepare users for the change involved with the consolidation process.

Slalom is a next-generation professional services company creating value at the intersection of business, technology, and humanity. Reach out to us at go.slalom.com/Slack to discuss how we can partner on your Slack consolidation.