Skip to content

SYSTEM Cited by 1 source

Enterprise Grid (Slack)

Enterprise Grid is Slack's product tier for its largest customers, introduced in 2017. It lets a single customer administer multiple Slack workspaces under one org container: a shared admin surface, shared billing, shared security policies, and the ability for data (notably cross-workspace (XWS) channels) to be stored at the org level and made visible across all workspaces on the Grid.

Shape before Unified Grid

In the original Enterprise Grid design (Source: sources/2024-08-26-slack-unified-grid-how-we-re-architected-slack-for-our-largest-customers):

  • Each user still navigates from the perspective of an individual workspace — the session token carries a workspace ID (see concepts/session-token-embedded-routing-context).
  • Some data is workspace-level (lives on the workspace's database shard); some is org-level (lives on the org's shard, visible across workspaces).
  • Backend reads check the workspace shard first and — for Enterprise Grid customers — fall back to the org shard if not found. Permissions are checked at both workspace and org levels.
  • Cross-workspace channels (XWS) are org-level entities.
  • The client stores data per workspace with distinct login sessions; switching workspaces means switching client state.

Over time the usage pattern shifted — a significant portion of Enterprise Grid users belonged to multiple workspaces on the same Grid — and the compensating patches (Threads view, Unreads view, XWS channels) added org-wide surfaces on top of the workspace- centric substrate. That mismatch is what Unified Grid (systems/unified-grid) ultimately re-architected.

Shape after Unified Grid

Enterprise Grid is still the product; Unified Grid is the re-architected client + API shape that presents it. Under Unified Grid:

  • The Enterprise Grid user boots with an org-wide view of all channels, DMs, and data the user can access across the Grid.
  • The workspace is available as a user-facing filter, not as a structural scope the backend routes by.
  • Three API-level migration strategies handle the formerly-workspace-routed APIs (see systems/unified-grid).
  • The worst-case "relevant workspaces" fan-out per user is capped at 50 (concepts/bounded-fan-out-relevance-cap).

Scale signal

Some Enterprise Grid customers have "thousands of workspaces" on a single Grid (Source: sources/2024-08-26-slack-unified-grid-how-we-re-architected-slack-for-our-largest-customers). This is what forced the prior RTM-stack rework to stop fanning org-wide data out to every workspace — and what the 50-workspace cap bounds on the API side.

Seen in

Last updated · 470 distilled / 1,213 read