Multi-tenant permissions done right: What Slack, Notion, and Linear can teach us

Every B2B SaaS app starts with the same three roles: Admin, Member, Viewer. For a while, that's enough. Then one enterprise customer needs a "Billing Manager" that can access invoices but not user settings. Another wants an "External Contractor" role with read access to two projects and nothing else. A third has a compliance team that needs audit log visibility without the ability to change anything.

You could keep adding roles to your global list. But now you have 30 roles, half of which exist for a single customer, and every new role is visible to every organization in your app. This is the role explosion problem, and it's one of the hardest practical challenges in building multi-tenant authorization.

The good news is that some of the most widely adopted SaaS products have already solved this in production, at massive scale. Slack, Notion, and Linear each take a different approach to per-tenant permissions, but they converge on a set of patterns that any B2B developer can learn from.

Let's break down what each of them does and pull out the patterns worth stealing.

Slack: System roles, custom roles, and scoped delegation

Slack's permission model has evolved significantly over the years. In its early days, Slack offered a straightforward hierarchy: Primary Owner, Owners, Admins, Members, and Guests. Each workspace had one set of roles, and those roles were the same everywhere.

That worked fine when Slack was a tool for small teams. But as enterprise adoption grew, the limitations became obvious. Making someone an Admin just so they could manage channels also gave them the ability to view dashboards and access settings that had nothing to do with channel management. The blast radius of a single role was too wide.

Slack's response was to introduce system roles, available on Business+ (with a limited set) and Enterprise plans. System roles like Channels Admin, User Admin, Compliance Admin, and Roles Admin each bundle a narrow set of permissions around a specific administrative function. An IT team can delegate channel management to one person and compliance oversight to another, without handing out full admin access to either.

More recently, Slack added the ability to create fully custom roles on Enterprise plans. Org-level Roles Admins can define a role, pick from a set of available permissions, and assign it to individuals or IdP groups. These custom roles can also be scoped to specific workspaces within an Enterprise Grid organization, meaning one person might be a Channels Admin in the Engineering workspace but have no elevated permissions in HR.

The patterns to notice here:

• ‍Granular permission primitives came first. Before Slack could offer custom roles, it had to decompose its admin capabilities into discrete, assignable permissions. Without that groundwork, custom roles would just be aliases for the same coarse-grained access.‍
• Delegation is scoped to entities. A role isn't just "what you can do" but also "where you can do it." Assigning a system role at the org level versus a specific workspace is a fundamentally different grant. This entity-scoping is what prevents a single admin role from becoming an all-access pass.‍
• IdP group mapping closes the loop. Slack lets organizations assign roles via IdP groups, which means role assignment can be automated through the customer's existing identity provider. Onboarding a new employee into the right role becomes a side effect of adding them to the right group in Okta or Entra ID.

Notion: Layered permissions with teamspace-level overrides

Notion's approach to permissions is less about named roles and more about layered access scopes that cascade from the workspace level down to individual pages.

At the workspace level, Notion defines four roles: Workspace Owner, Membership Admin (Enterprise only), Member, and Guest. These roles control who can change workspace settings, manage people, and access content by default. But the real flexibility comes from teamspaces.

Teamspaces are sub-containers within a workspace, each with its own membership list, permission levels, and security settings. A teamspace owner can decide whether the space is open, closed, or private. They can set default permission levels for teamspace members versus non-members. And on Enterprise plans, they can override workspace-level security settings for their specific teamspace, like enabling guest access in one teamspace while it's disabled everywhere else.

This creates an inheritance model where workspace-level settings serve as the baseline, and teamspace-level settings can tighten or (for workspace owners) loosen the rules for a specific group. Within a teamspace, individual pages can be shared with even more granular permissions: Full Access, Can Edit, Can Edit Content, Can Comment, or Can View.

Notion also supports permission groups, which are named collections of users that can be added to teamspaces or pages in bulk. When combined with SCIM provisioning, groups defined in an identity provider can automatically flow into Notion and determine who lands in which teamspace with which access level.

The patterns to notice here:

• ‍Inheritance with override creates flexibility without chaos. Notion doesn't ask every teamspace owner to configure permissions from scratch. Sensible defaults cascade from the workspace level, and overrides are only needed for exceptions. This dramatically reduces the surface area of permissions that any one person has to think about.‍
• Content-level permissions supplement role-level permissions. Not everything maps cleanly to a role. Sometimes you need one specific person to have edit access to one specific page, regardless of their broader role. Notion's page-level sharing handles this without requiring a new role definition.‍
• The "highest permission wins" rule keeps things predictable. When a user has access through multiple paths (workspace membership, teamspace membership, direct page share), Notion resolves conflicts by granting the highest level. This is simple to reason about and avoids the common trap of conflicting deny/allow rules creating unpredictable access.

Linear: Team-level delegation with a lean role model

Linear takes a more opinionated approach. At the workspace level, there are only a handful of roles: Admin, Member, and Guest on most plans, with a dedicated Owner role added on Enterprise plans that carries access to the most sensitive settings like billing, security, and audit logs. There are no custom workspace-level roles, and Linear's documentation is explicit about this being a deliberate choice. The role model is intentionally lean.

Where Linear gets interesting is at the team level. Linear recently introduced the concept of team owners, a role that exists only within the context of a specific team. Team owners get delegated control over settings that would otherwise require a workspace admin: they can manage who joins the team, control whether members or only owners can create and edit labels, manage workflows, and restrict team access to invite-only.

This team-owner pattern solves a specific organizational pain point. In a growing company, you don't want every team lead filing a request with a workspace admin every time they need to adjust a workflow or add a contractor. But you also don't want to make every team lead a workspace admin. Team owners sit in the middle: they have autonomy over their domain without visibility into or control over the rest of the workspace.

Linear also supports private teams on Business and Enterprise plans. Issues, projects, and members of a private team are invisible to anyone outside the team. Even workspace admins on non-Enterprise plans get a warning before they can view or join a private team. This is a blunt but effective access control mechanism for sensitive work like HR, M&A, or executive planning.

The patterns to notice here:

• ‍A minimal global role model can work if you delegate at the right layer. Linear proves you don't need dozens of workspace-level roles if you push the right controls down to the team level. The key is identifying which decisions should be centralized and which should be delegated.‍
• Team-scoped roles solve the "admin bottleneck" without admin sprawl. Instead of creating increasingly specific workspace-level admin roles (Label Admin, Workflow Admin, Team Membership Admin), Linear collapses all of those into a single team owner concept that only applies within a team's boundary.‍
• Private teams are a first-class access control primitive. Rather than trying to model visibility restrictions through permissions alone, Linear treats team privacy as a structural property. This is easier to understand and harder to misconfigure than a complex set of view permissions.

The shared patterns

Despite their different architectures, Slack, Notion, and Linear converge on a few ideas that any B2B developer should internalize:

• ‍Scoped customization over global role lists. All three products avoid the trap of having one giant list of roles that every customer has to look at. Instead, they let customization happen at the right boundary: per-workspace in Slack, per-teamspace in Notion, per-team in Linear. The specific boundary varies, but the principle is the same. Keep the global model simple and push variation to the edges.‍
• Sensible defaults with opt-in complexity. None of these products require customers to configure permissions from day one. Slack workspaces start with the standard role hierarchy. Notion teamspaces inherit workspace settings. Linear teams let any workspace member join by default. Complexity is available when you need it, but it's not the starting point.‍
• Identity provider integration as the scaling mechanism. Manual role assignment breaks down at scale. All three products support mapping IdP groups to roles or team memberships, which means the customer's IT team can manage access through the tools they already use. This is table stakes for enterprise readiness.‍
• Structural access controls alongside permission-based ones. Private teams in Linear, private teamspaces in Notion, and workspace-scoped roles in Slack all use structural boundaries (not just permission flags) to control access. Structural controls are easier to audit and harder to accidentally misconfigure.

What this means for your app

If you're building a B2B application and your permission model is still a flat list of global roles, you're going to hit a wall. The question isn't whether your customers will ask for per-organization customization. It's when.

The approach these products point to is straightforward: define a clean set of permission primitives, group them into sensible default roles, and then let individual organizations create custom roles scoped to their tenant without polluting the global role list.

How WorkOS supports org-scoped roles and IdP syncing

This is exactly the problem that organization roles in WorkOS solve. You start by defining environment-level roles and permissions that apply across your entire app. These are your sensible defaults, the equivalent of Slack's built-in hierarchy or Linear's Admin/Member/Guest model. Every organization inherits them automatically.

When a specific organization needs something different, you create an organization role scoped to that tenant, either through the WorkOS dashboard or the Organization Roles API. That role gets its own set of permissions, its own default role, and its own priority order, all independent from the environment. Other organizations are completely unaffected. This is the same pattern Slack uses with workspace-scoped custom roles and Notion uses with teamspace-level permission overrides: keep the global model clean and push customization to the boundary where it belongs.

The second piece is IdP role assignment. Every product we looked at supports syncing roles from identity providers, and for good reason: manual role assignment doesn't scale past a handful of users. WorkOS supports role mapping through both SCIM directories and SSO connections.

• With SCIM, you map a customer's directory groups (like "Engineering" or "Finance") to roles in your app, and every user provisioned from that group automatically gets the right role.
• With SSO, IdP group memberships are sent as attributes at login and resolved against your configured group-to-role mappings.

You can do this mapping yourself in the WorkOS dashboard, or you can hand it off to your customer's IT admin through the Admin Portal. When role assignment is enabled in the Admin Portal, IT admins can map their own directory groups to your app's roles during setup, without involving your team at all. This is the self-serve delegation model that enterprise customers expect, and it's the same pattern Slack uses when it lets Roles Admins assign custom roles via IdP groups.

The best multi-tenant permission systems aren't the most complex ones. They're the ones that start simple and let complexity emerge at the right boundary, owned by the right people. WorkOS RBAC is designed to make that straightforward.