B2B SaaS Roles and Permissions: Designing Access Control That Scales
Designing roles and permissions for B2B SaaS: RBAC vs attribute rules, default and custom roles, resource access, admin UX, SSO and audit logs.
How should B2B SaaS roles and permissions work?
Define permissions as fine-grained actions on resources, group them into a few clear default roles that match how customers work, add resource-level sharing or attribute rules where roles are not enough, enforce every check on the server in one authorisation layer, give administrators a clear interface and audit log, connect to SSO and provisioning for larger customers, and test permissions automatically. Good access control is both a security feature and a usability feature.
This guide is for SaaS product managers, designers and engineers. For tenant isolation, see multi-tenant SaaS architecture; for API enforcement, API security best practices.
Key takeaways
- Model permissions as actions on resources; roles group them.
- Start with three to five default roles customers recognise.
- Add resource-level sharing for projects, teams or records.
- Enforce on the server in one place; the UI only reflects it.
- Audit every permission change and sensitive action.
- Test every role against every resource type.
Access control models
| Model | How it works | Good for |
|---|---|---|
| Role-based (RBAC) | Users get roles; roles grant permissions | Most B2B products; easy to explain |
| Resource-level sharing | Users or teams are granted access to specific projects or records | Collaboration tools, client portals |
| Attribute-based (ABAC) | Rules based on attributes such as region, department or classification | Complex enterprises, regulated data |
| Relationship-based | Access follows relationships (owner, member of, manager of) | Hierarchies and nested resources |
Designing default roles
Base roles on real jobs: owner or billing administrator, administrator, member, and limited or guest users are common. Write each role's purpose in one sentence, list its permissions, and check them against customer interviews. Keep billing and security settings separate from day-to-day administration, and make the least-privileged role the default for new invites.
Administrator experience
- Show what each role can do in plain language.
- Let administrators preview a user's effective access.
- Make inviting, changing and removing users quick, with bulk actions.
- Show who has administrator access and when it was granted.
- Provide an audit log of permission changes and sensitive actions.
- Support SSO, group-to-role mapping and automated provisioning (often via SCIM) for larger customers.
Enforcement and testing
Centralise authorisation in a shared layer or service that every endpoint uses, checking the user, tenant, role and resource for each request. Avoid scattered ad hoc checks. The OWASP Authorization Cheat Sheet recommends denying by default and validating permissions on every request (OWASP). Write automated tests for each role, including attempts to reach other tenants' data and admin functions, and run them on every change.
Common mistakes
- Permission checks only in the front end.
- Dozens of roles nobody understands.
- Everyone invited as an administrator by default.
- No audit log of permission changes.
- Users removed from SSO but still active in the product.
Hypothetical example: a project management SaaS
This example is hypothetical. A project tool started with owner and member roles. Larger customers asked to give clients read-only access to one project and to stop members deleting projects. The team modelled permissions as actions on workspaces, projects and tasks, introduced administrator, member and guest roles, and added project-level sharing for guests. All checks moved into one authorisation module, with automated tests for each role and cross-tenant access attempts. Enterprise customers got SSO with group-to-role mapping and an audit log export.
Example permission matrix
| Permission | Owner | Admin | Member | Guest |
|---|---|---|---|---|
| Manage billing | Yes | No | No | No |
| Manage users and roles | Yes | Yes | No | No |
| Configure SSO and security | Yes | Yes | No | No |
| Create projects | Yes | Yes | Yes | No |
| Edit shared projects | Yes | Yes | Yes | If granted |
| View shared projects | Yes | Yes | Yes | If granted |
| Export data | Yes | Yes | Configurable | No |
Related guides
- Multi-tenant SaaS architecture for tenant isolation.
- API security best practices for object-level authorisation.
- B2B account management for buyer roles in commerce.
- Secure web application development for broader security practice.
- Automated regression testing for keeping permission tests running.
Conclusion
Roles and permissions scale when they are modelled cleanly, explained clearly and enforced centrally. Start with a few roles that match real jobs, add resource-level access where needed, support enterprise identity, audit changes and test relentlessly. For employee access across your own business systems, see joiner-mover-leaver automation. To record who changed what, see SaaS audit logging.
Designing access control for your product?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on SaaS administration UX and secure SaaS engineering. If it would help to review your permission model, we are happy to talk it through.
Common questions.
Most B2B SaaS products start with role-based access control (roles grouping permissions) because it is easy for customers to understand. Add attribute or relationship rules, such as access to a project or a region, where roles alone cannot express real needs. Many products combine roles with resource-level sharing.