How to Manage Slack Collaboration at Scale with Enterprise Grid

For many organizations using Slack, adoption began with a few groups who needed a dedicated workspace in which to collaborate. As more groups discovered Slack collaboration, these workspaces proliferated with little thought for administration. As organizations continue to grow their use of Slack collaboration, Slack’s Enterprise Grid offering gives IT administrators a set of tools to bring all these workspaces together and manage them at scale.

Intended for organizations with more than 500 users, Slack Enterprise Grid makes it possible to manage multiple workspaces in an organization hierarchy. This means administrators can manage users and workspaces cohesively, as opposed to managing workspaces individually with the Standard and Plus Slack plans. In addition, the Enterprise Grid enables end users to search across workspaces and communicate across workspaces using default and multiworkspace channels. This article details how an administrator can use Enterprise Grid to manage default and multiworkspace channels, as well as how to streamline user management.

Default channels give companies a way to make sure that all end users see certain company-wide communications, as well as have the ability to opt in or out of certain communications. This makes it possible for an organization to communicate with all users despite, even those who may just use a single, role-specific workspace. To set up default channels beyond the #general channel, use the “Channel Administration” tool to specify whether channel membership is optional or required and who can post to a channel.

Default channels must be public, organization-wide and multiworkspace. As with Standard and Plus, Enterprise Grid supports threaded replies by members to a default channel. Administrators need to plan a default channel strategy in advance of moving to Enterprise Grid, however, as there is a limit of 25 default channels per organization. For large organizations, this limitation may cause some angst as various groups will want (and expect) to manage their own company-wide communications. As part of a migration to Enterprise Grid, organizations should consider establishing a working group comprising key stakeholders representing various departments. This will help establish a communications protocol that prevents a proliferation of unnecessary channels.

In addition to being used to create default channels, multiworkspace channels can be limited in scope to allow collaboration across select teams within a company. For example, say a company with direct and indirect sales organizations has created separate workspaces for each. By setting up a multiworkspace channel, an administrator can ensure that all sales teams across both channels receive critical information about pricing, events and training. Under the “Channel Settings” menu, the administrator can use “Additional options” to add that channel to both the direct and indirect sales teams’ workspaces.

Channel administrators and owners can also specify if a channel will be public (anyone can join and the channel is searchable by others) or private. It is worth noting that while workspace administrators and owners may be able to manage their own channels today, when a company establishes an organization with Enterprise Grid, it can set up policies that will override established workspace policies related to who can create and manage workspaces and channels. Administrators need to weigh the pros and cons of letting groups manage their own workspaces and channels versus a more hierarchical approach.  

For larger organizations, managing users--particularly as people come and go from a company--can be particularly time consuming for administrators. Having the organizational-level structure available in Enterprise Grid means administrators who have to add and remove user accounts can do so once, at a macro level, either within Enterprise Grid or their enterprise directory, rather than having to make multiple changes in different workspaces.

Administrators can provision users through the SCIM (System for Cross-domain Identity Management) standard and the SCIM API. Supported identity providers include Google G-Suite, Okta, Microsoft Azure Active Directory, OneLogin and Ping Identity. These providers can be used to live sync with on-premises Active Directory groups.

This means that administrators can use groups to add users to, or remove users from, workspaces in bulk. Furthermore, administrators can use identity provider provisioning to make sure membership stays in sync with the organization's directory. They can also ensure that mistakes by end users and users with administrative privileges don’t impact access to a workspace. With the auto-provisioning option enabled, end users can’t deactivate an account and workspace owners can’t add someone to a workspace group who does not belong to the corresponding group in the organization’s directory service.

If a company has adopted Slack collaboration organically and has moved to Enterprise Grid, the decentralized beginnings of an organization’s different workspaces can mean that an employee leaving the company may affect many workspaces in many different ways.

For example, if a user who has added applications to a number of workspace leaves, some of those applications may stop working. To see who owns various applications, administrators can use the Admin Dashboard to export a report that includes who installed applications, the application source and its access rights. This gives administrators an opportunity to proactively filter which apps a user has installed and make sure that multiple workspaces don’t have an application go offline.