Slack launched in 2013 with a beautifully simple data model: users belong to workspaces, workspaces contain channels, channels contain messages. To view a different workspace, you click on it and context switches entirely. For small teams using a single workspace, this model was perfect. For large enterprises that had grown to 50, 100, or 200 workspaces across departments, geographies, and business units, it was a prison. Every DM, every notification, every unread count, every search result was siloed by workspace. A VP with access to 80 workspaces had to remember which workspace a conversation was in, click to it, check notifications, return, and repeat — dozens of times per day. The architecture was working against the users it was supposed to serve.
Slack's team had been papering over the workspace-centric limitation for years with increasingly complex workarounds. The feature, multi-workspace management tools, org-wide settings — all of them were workarounds that added complexity without fixing the fundamental architecture. The CTO and engineering leadership faced a classic build-it-now-or-keep-patching decision. They chose to build. The project was called Unified Grid, and it would require rebuilding the core data model, refactoring thousands of APIs, and redesigning both the backend and every client application — simultaneously.
THE WORKSPACE-CENTRIC ASSUMPTION
In Slack's original architecture,
almost all data was particular to a single workspace: messages, channels, DMs, notification preferences, user profiles, unread counts. This assumption was baked into thousands of database queries, API responses, and client rendering paths. To build Unified Grid, every piece of data that needed to be visible across workspaces had to be lifted out of the workspace silo — a change that touched nearly every system in the stack.
🏢Slack's largest enterprise customers operate across dozens to hundreds of workspaces. Expecting those users to manually context-switch between workspaces to find conversations, check notifications, or respond to DMs was creating real productivity friction. The Unified Grid project was not a technical exercise — it was a direct response to enterprise customer feedback.
Problem
Enterprise Users Drowning in Workspace Context-Switches
Slack's workspace-centric model forced enterprise users to manually navigate between dozens of workspaces to find conversations and check notifications. Key features like a unified DM inbox, an org-wide activity feed, and cross-workspace search were impossible within the existing architecture — not missing features, architecturally blocked features.
Cause
The Foundation Assumption Was Wrong for Enterprise
Slack's data model had been built on the assumption that almost all user data is particular to a single workspace. Ten years of feature development had embedded this assumption deep into database schema, API contracts, and client rendering logic. Supporting org-wide views required either a rewrite or an ever-growing layer of workarounds.
Solution
Prototype the Path: Build Incrementally, Prove Out
Rather than committing immediately to a full rewrite, Slack's team built a proof of concept using Unified Grid within internal tooling — Slack's own employees using it daily. Only after the POC validated the architecture and revealed what work was required did the team commit to a full rollout. Slack calls this 'prototyping the path.'
Result
Shipped After 2 Years: Rollout Sep 2023 → Mar 2024
Unified Grid rolled out to customers starting Fall 2023 and completed in March 2024. Features like the unified DMs tab, org-wide Activity tab, and Save it for Later became possible on a foundation that had been impossible on the workspace-centric model. The rewrite that everyone said you shouldn't do turned out to be necessary.
The Unified Grid project used a strategy Slack calls prototyping the path — building incrementally, proving out ideas in practice before committing to the full scope. Rather than designing the complete architecture and then building it, the team built a barely functional prototype of Unified Grid and deployed it to Slack's own internal teams. Using it daily for their own work surfaced what was broken, what the real user experience gaps were, and what the engineering challenges would be in production — all before the team had committed to building the entire thing. By Summer 2023, Unified Grid was stable enough that much of the company used it daily. By Fall 2023, external rollout began. By March 2024, it was complete.
WHAT HAD BEEN TRIED BEFORE
Slack had tried to alleviate the workspace-switching problem incrementally before committing to Unified Grid:
Shared Channels allowed cross-workspace channel sharing.
Connect enabled messaging across organizations. Various UI improvements consolidated workspace-switching. None of these fixed the fundamental architecture — they were features built on a wrong foundation that made the foundation slightly less painful without changing it.
🔍Cross-Workspace Search: The Clearest User Pain
One of the most cited enterprise frustrations was search. Searching for a message required knowing which workspace it was in first, then switching to that workspace, then searching. Unified Grid enabled org-wide search that returned results from all accessible workspaces simultaneously. For users with 80 workspaces, this changed search from a manual process into a useful feature.