SaaS permission matrices: model actions before role names

Define ownership and scope

For a fictional expense platform, “manager” is ambiguous. Can a manager see every department, alter an approved claim or export receipts? Model organisation membership, team scope and record ownership explicitly. Enforce the decision on the server; hiding a button is not an access-control boundary.

Draft a small matrix

This example is not a universal policy. Some customers require stronger separation of duties, while others need delegated access across teams. Capture those requirements before promising a role model.

Test denied access, not only successful flows

Create two organisations and attempt reads, edits and exports using another tenant's object identifier. Include attachments, search and background jobs. Recheck old sessions after removing a role so revoked privileges do not remain effective indefinitely.

Are two roles enough for a first release?

They can be, when their limits are clear. Add a permission to support an observed workflow rather than an impressive settings screen. Every new capability should have an owner, a defined data scope and a negative test showing that an unauthorised user cannot exercise it.

A contractor working for several customers

Test a consultant who belongs to multiple customer organisations. Removing access to one customer must not delete their personal identity or preserve that customer's files in another workspace. This scenario is useful for professional-services SaaS sold internationally.

Examples are educational and do not describe client results. Content prepared with AI assistance; see our editorial policy. Our method ↗