What should a SaaS permission model describe?
A permission model should describe who may perform a specific action on a specific resource within a verified organisation and under any necessary conditions. Begin with business operations such as viewing an invoice, approving a refund or inviting a member. Roles are useful collections of those permissions, but they should follow the work rather than substitute vague labels such as user and admin for an actual authority model.
Separate identity, membership and authority
One person may belong to several customer organisations and hold a different role in each. Model the person, their membership and the permissions active within the selected tenant as separate concepts. Authentication proves identity; it does not by itself establish which organisation the person represents or what they may do there.
Write permissions as actions on resources
Use stable concepts that match the product, such as order.view, order.refund or member.invite, rather than permissions tied only to individual buttons or routes. The same decision must protect web screens, APIs, background actions and administrative tools. A hidden button is useful interface behaviour, but it is not enforcement.
How should the first roles be chosen?
Choose a small set of roles from responsibilities that appear repeatedly across customers, then assign each the minimum permissions needed to perform that work. Start with understandable defaults that a customer administrator can predict. Avoid role hierarchies that inherit broad authority merely because one job title sounds more senior; responsibility for billing, people and operational approval may belong to different staff.
Use workflow evidence rather than organisational charts
Observe who creates, reviews, approves, corrects and exports information in representative customer organisations. Two people with the same job title may have different responsibilities, while several titles may perform the same product role. Build the default around stable work patterns and record where customer variation is real rather than assuming every organisation operates alike.
Keep the administrator role bounded
A tenant administrator may manage membership and configuration without needing access to every sensitive record or financial action. Separate account administration from unrestricted business authority where the consequences justify it. The platform's own support or operator role should also remain distinct from customer administration and receive explicit, auditable access.
Deny permissions that have not been granted
A request that does not match an explicit permission should be rejected. This makes new features safer because adding a resource or operation does not silently make it available to every existing role. It also gives reviewers a clear question: which role needs this action, in which tenant context, and why?
When are roles alone not enough?
Roles alone become insufficient when authority depends on the relationship to a particular record, the record's state, a spending limit, location, ownership or another contextual fact. Add a narrow condition or relationship to the permission decision rather than multiplying roles for every combination. Keep the rule explainable and testable so flexibility does not turn access into an unpredictable policy language.
Use relationships for record-specific authority
A case worker may edit cases assigned to their team, while a customer can view only records connected to their account. That distinction is better expressed through a verified relationship than through a new role for every team or customer. The decision should use trusted server-side data, not a tenant, owner or role value supplied by the client.
Use attributes for bounded operating rules
Approval limits, region, employment status or record state may qualify an otherwise valid permission. Apply these attributes deliberately and document where their values come from, how quickly changes take effect and what happens when data is unavailable. A condition that cannot be explained to an administrator or support team will be difficult to operate safely.
Resist per-user exceptions
Direct grants feel convenient but become difficult to review as people move roles and organisations. Prefer role, relationship or policy changes that explain the legitimate pattern. If an exceptional temporary grant is necessary, give it an owner, reason, expiry and audit record so it cannot become invisible permanent access.
Should customers be allowed to create custom roles?
Offer custom roles when customers have recurring legitimate differences that fixed defaults cannot represent and when the product can make the consequences understandable. Preserve protected platform rules, provide safe templates and prevent combinations that violate separation of duties. Customisation creates continuing responsibilities for migration, support, review and testing, so it should solve evidenced customer needs rather than signal enterprise maturity by itself.
Keep mandatory restrictions outside customer control
A customer-defined role must not escape its tenant, grant platform-operator capability or bypass controls the service is responsible for enforcing. Some sensitive actions may always require a particular account owner, recent verification or a separate approver. Define these invariants before exposing a permission editor.
Show effective access before saving
Permission labels should describe business consequences in plain language. Group related actions, expose dependencies and warn when a selection grants sensitive export, financial or membership authority. Let administrators preview what the role can do and identify who currently holds it. An editor that displays dozens of technical switches without context transfers product complexity to the customer.
Plan for permission model changes
When a new product capability introduces permissions, define how default and custom roles receive them. Automatically granting a sensitive new action may expand access unexpectedly; withholding every new action may break expected workflows. Classify the permission, choose a migration rule and communicate the effect to administrators who own custom roles.
How can a team prove permissions work correctly?
Test permission decisions as a matrix of tenant, actor, role, resource, action and relevant condition, with equal attention to rejection. Verify direct API calls, identifiers belonging to another tenant, stale memberships, background jobs, exports, support access and role changes during active sessions. Record enough safe audit information to explain consequential grants, denials and administrative changes without exposing unrelated customer data.
Test negative cases as product behaviour
For every important allowed action, test a valid user who lacks the permission, a valid user from another tenant and a request with misleading client-supplied context. Include indirect paths such as bulk actions, search, files and generated reports. Permission confidence comes from showing that nearby but unauthorised cases fail safely, not only that the expected user can complete the task.
Make access review possible
Customer administrators should be able to see who has each role and what that role currently permits. Provide a practical route to remove access, review privileged assignments and find temporary exceptions. Internally, monitor unusual denied attempts and privileged actions while keeping the audit trail separate from the decision itself.
Treat permission design as product design
Roles affect onboarding, delegation, support, pricing and customer trust as well as security. Twofold's SaaS architecture and product work can help map responsibilities into a permission model, establish tenant-aware enforcement and design the administrative experience needed to operate that model as customers and features grow.