Topic starter
06/06/2026 2:34 am
TL;DR: B2B SaaS permission models fail when global role lists grow faster than tenant-specific needs, creating role explosion and overbroad access, according to WorkOS’s analysis of Slack, Notion, and Linear. The governing principle is to keep the global model simple and push variation to the tenant boundary, where scoped delegation is actually controllable.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Multi-tenant permissions done right: What Slack, Notion, and Linear can teach us”.
Key questions
Q: What breaks when every tenant request becomes a new global role?
A: The model breaks because the global catalogue becomes a dumping ground for exceptions.
Q: Why do scoped tenant roles reduce overbroad access in SaaS apps?
A: Because scope is part of the grant, not an afterthought.
Q: How do teams know whether their role model has become too complex?
A: A role model is too complex when most new roles exist for one tenant, administrators cannot explain why a role is global, or access reviews require constant exceptions.
Practitioner guidance
- Define permission primitives before roles Break administrative capabilities into discrete actions first, then compose only the minimum roles needed for tenant administration and reporting.
- Scope custom roles to tenant objects Attach custom permissions to workspaces, teamspaces, teams, or equivalent tenant containers so one customer's exception cannot become everyone else's baseline.
- Map identity groups to tenant roles Use SCIM or SSO group claims to assign tenant-scoped access so onboarding and role changes follow the customer's directory structure.
Bottom line: Role explosion is a structural authorisation problem that appears when tenant-specific exceptions are stored in a shared global role list.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 12 hours ago by NHI Mgmt Group
06/06/2026 4:19 am
Global role sprawl is a governance failure, not a product feature: once tenant-specific exceptions are encoded as shared roles, the authorisation model stops describing business intent and starts accumulating noise. That makes access harder to review, easier to over-grant, and more brittle to change. The practical conclusion is that multi-tenant RBAC must be designed around local variation, not global enumeration.
A few things that frame the scale:
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Should tenant-specific access be handled with custom roles or private spaces?
A: Use custom roles when the difference is about what a user can do. Use private spaces when the difference is about what a user should be able to see at all. The two controls solve different problems, and the cleanest models often use both so privilege and visibility do not get mixed together.
👉 Read our full editorial: Multi-tenant permissions need scoped roles, not global role sprawl
This post was modified 12 hours ago by NHI Mgmt Group