When Workspace-Centric Architecture No Longer Fits

Slack launched in 2013 with an assumption baked into its core: every user belongs to a single workspace, and all data—channels, messages, permissions—lives within that workspace's silo. To see another workspace you had to click out of the current one. That model worked until Enterprise Grid arrived in 2017, letting large organizations split into multiple workspaces under one umbrella org.

At first, Enterprise Grid users typically stayed in one workspace. Over time, that changed. Today, many users belong to several workspaces, and Slack introduced views that pull data across them, like Threads and Unreads, plus cross-workspace (XWS) channels. The gap between how the product was built and how it was being used widened into an obvious question: if a user could access multiple workspaces within the same org, why not present all their data in a single unified view?

Such a shift would remove the context-switching tax and a class of bugs stemming from syncing org-wide data across workspaces. It would also cut API calls by fetching data for multiple workspaces at once. But Slack was architected on workspace-scoped assumptions. Making this real would mean overhauling thousands of APIs, database queries, and permission checks.

Unified Grid provides powerful organizational concepts like the DMs tab, the Activity Tab, and Save it for Later, while still allowing users to filter by workspace.

Where the Workspace-Centric Model Came From

Originally, each Slack workspace mapped to a single customer and was stored on its own database shard. Clients authenticated API calls with session tokens containing both user ID and workspace ID, which the backend used to route each query to the right shard and enforce access control. The client mirrored this model with a separate data repository and login session per workspace.

The original Slack data model routed all queries to a database shard identified by the workspace ID in the session token.

As Slack grew, teams within the same company kept spinning up separate workspaces. Enterprise Grid solved the administration problem by adding an "org" that acts as a parent to multiple workspaces. Some data then lived at the org level—XWS channels, for example, were stored on the org's shard and visible across workspaces. The backend learned to check the workspace shard first, then fall back to the org shard, and to verify permissions at both levels.

In Enterprise Grid, the backend queries both the workspace and org shard to resolve data stored at the org-level (and therefore available to all workspaces on the Grid).

The Path to an Org-Wide View

Users in Enterprise Grid began living in multiple workspaces, and the workspace-centric client required constant switching, which caused missed activity and frustration. Slack had already laid groundwork that pointed toward a fix. The Vitess migration introduced sharding along axes other than workspace or org ID, so routing no longer depended on workspace context for major tables. The real-time messaging (RTM) stack no longer needed to fan out org-wide data to every workspace, and clients started sharing org-wide data across workspaces, enabling aggregated views like Threads and Unreads.

Even with those changes, the workspace-scoped client remained the core constraint. To truly go org-wide, Slack had to update APIs, database queries, and permissions checks across the entire stack. Rather than tackle thousands of potentially broken APIs upfront, the team built a proof of concept—prototyping the path—for internal dogfooding.

The first step was a new boot API that returns all workspaces and channels a user has access to across their entire org. Clients were updated to store this data at org level, no longer navigating from a single workspace's perspective. Next, Slack's homegrown API framework was extended so individual APIs could be marked compatible with this new Unified Grid client. As engineers used the client daily, they fixed broken APIs using a few strategies:

  1. Route without workspace context. APIs already in the new sharding scheme—like those reading the messages table, sharded by channel ID—were marked compatible without major changes.
  2. Ask the user. If an API acted directly on a workspace, the client prompted the user to pick one (e.g., the channel creation flow now requires the user to choose a target workspace).
  3. Iterate over workspaces. As a fallback, resolve the query by trying each relevant workspace's shard. Most users are in only a handful, so performance is fine. Heavy outliers—often admins in hundreds of workspaces—were handled by capping the number of "relevant" workspaces at 50, with manual configuration for the rest.

With Unified Grid, in the worst case the Slack backend queries the shard for every Enterprise Grid workspace the user belongs to when loading workspace-level data.

The prototype had rough edges, but insiders found the workflow simpler without workspace switching. Slack began opting in more employees, eventually executives. The response was decisive enough to move to production.

Taking the Prototype to Production

Unified Grid touched nearly every API and permission check the client invokes. With an org-wide redesign, code from dozens of teams needed verification across the board. The effort was folded into IA4, the client redesign introducing Activity, DMs, and Later tabs, to avoid subjecting customers to two major overhauls at once. General availability became a serious company priority.

The team enumerated every client-invoked API and permission check into spreadsheets, dividing ownership among product teams. Engineers made two passes on each API: a first pass to support internal usage, then, weeks later, a hardening pass for integration tests, permission edge cases, and API behavior.

The core team shifted focus from hand-fixing to building infrastructure that scaled the migration:

  • Docs. A detailed guide walked engineers through making each API work in Unified Grid, including the strategies above.
  • Tests. A parallel integration test suite ran all existing tests with org context instead of workspace context, reusing thousands of tests and providing a concrete checklist of what was broken.
  • Helpers. Convenience utilities simplified fetching channels and running permission checks across a user's entire Enterprise Grid. For example, admin checks in a cross-workspace channel inspect whether a user is an admin in any linked workspace or at the org level.
  • Client Infrastructure. The workspace-scoped data repositories needed migrating to an org-wide model. Clients took different approaches—some added an org-level store while retaining workspace-scoped repositories; others moved entirely to a single store. These migrations were shipped incrementally, derisking the broader project.

We created a spreadsheet to track the number of APIs and permission checks we needed to fix, and enjoyed watching the graph tend towards zero.

Prototyping the Path Forward

By summer 2023, a large share of Slack was dogfooding Unified Grid daily. Customer rollout began in fall 2023 and wrapped up in March 2024. What started as a barely functional prototype had become, in just under two years, the backbone of Slack's redesigned client and a foundation for new features.

The common advice against large rewrites holds water, but it isn't absolute. When an application's architecture drifts too far from how people actually use it, exploring a rewrite via gradual prototyping can be the fastest route to the better product. With Unified Grid live, that flexible information architecture is fertile ground for building new experiences—with the path toward them still being prototyped along the way.