The pain
- The number of roles grows as tenants and teams multiply.
- One role set cannot answer same-group vs other-group access cleanly.
- Spreadsheets hide the pattern: who can see a customer record, who can edit it, and who must be blocked.
Use case
Multi-tenant SaaS access without role explosion
Many multi-tenant products hit the same problem: each new tenant, team, or customer segment creates yet another role. The result is a model that is hard to reason about and harder to approve.
The solution
- Keep one role set across tenants and model membership by context.
- Use relationship scope rules such as own, same group, other group, and superior.
- Add field-level conditions where only a few fields should change for a given audience.
Why the pattern matters
In multi-tenant SaaS, the important question is not simply “what role does this user have?” It is “what tenant, what group, and what relationship does this user have to the record?” That is where same-group vs other-group access, ownership, and field sensitivity become visible.