SaaS User Roles and Tenant Permissions: What to Plan First

In a SaaS platform, a tenant usually means a customer organization or workspace. Two organizations may use the same product while needing their records kept separate.

A login system answers who someone is. It does not by itself answer which organization’s records they may use. A role such as “manager” is also incomplete unless its scope is defined.

Start with membership and boundaries

Decide whether one person can belong to multiple organizations. Describe how they select a workspace, receive an invitation, and lose access.

For example, a consultant might belong to two customer workspaces. Being a reviewer in one should not make them a reviewer in the other. A staff member removed from an organization should not retain access because an old link still opens.

Write those situations as acceptance criteria in the SaaS MVP scope, rather than waiting until more customers join.

Build a permission matrix

Define actions that have a business meaning. “Edit” might include correcting a draft, changing an approved record, or changing the owner. Those may require different permissions.

Action	Workspace member	Reviewer	Workspace administrator
Create a request	If included in the workflow	If included in the workflow	If included in the workflow
View a request	Own or explicitly shared records	Assigned review records	Agreed workspace scope
Approve a request	No, unless explicitly authorized	Assigned requests	Only if approval authority is granted
Invite a user	Usually denied in this example	Usually denied in this example	Allowed within workspace rules
Export all workspace data	Denied in this example	Denied in this example	Separate explicit permission

This is an illustrative matrix. It is not a universal role model. Decide whether administrators should manage accounts without gaining authority to approve business decisions.

Enforce permissions beyond the interface

OWASP recommends denying access by default and checking authorization on every request. Hiding a button is useful for the interface, but it does not prevent a direct request to the server. OWASP authorization guidance

The server needs to validate the user’s current access to the specific resource and action. That includes a record reached through an identifier in a URL.

Avoid assuming a role name is enough. Access may also depend on organization membership, assignment, record state, or an explicit sharing relationship.

Include the less visible data paths

Tenant boundaries also matter in cached results, file storage, exports, search, and background processing. OWASP’s multi-tenant guidance addresses these areas, including tenant-aware cache scoping and authorization before protected cache access. OWASP multi-tenant guidance

Ask the development team how a background report knows which organization’s data it may include. Check whether an exported file remains accessible after access changes and what policy should govern that behavior.

If another system receives records, include the same boundary in the integration brief. Data should not lose its organization context when it leaves the main interface.

Define support access and ownership changes

Support staff may need to investigate a problem. Agree whether they can see customer records, who authorizes that access, how long it lasts, and what activity is recorded.

Also plan the departure of the last administrator, ownership transfer, and account closure. Those are product decisions as well as technical ones. They should not depend on an undocumented database change by a developer.

Test denied actions explicitly

Use separate test organizations and users. Try opening another organization’s record, exporting outside the permitted scope, acting after membership removal, and using an old invitation.

Check permitted actions too, so the boundary does not prevent legitimate work. Record the expected behavior for each scenario and repeat relevant checks when access rules change.

These planning steps do not certify a platform’s security. They make the required behavior clear enough to implement, review, and test.

KainoLab offers SaaS platform development. Share your workspace model and permission matrix with the team when discussing a new product or a focused extension.