How to Design Roles and Permissions in SaaS

A list of Admin, Manager, and Member roles is a starting point. It does not explain how the product should behave.

Consider a purchase-request application. One person prepares a request, another reviews it, and a third manages user access. Those responsibilities raise different questions:

• Who can see requests across departments?

• Who can change a draft?

• Can an approver change the request they are reviewing?

• Can someone approve their own submission?

• What happens when a request is returned for changes?

• Does managing accounts grant access to business records?

Map the workflow before deciding what each role includes. Identify who creates the work, who owns it, who reviews it, and what happens when it moves between them.

This prevents a common design mistake: giving users broad permissions because a narrower workflow has never been defined.

A role groups permissions around a responsibility. A permission authorizes a particular action. Scope identifies where that permission applies.

In role-based access control, or RBAC, permissions are associated with roles, and users receive authorized role assignments. NIST also describes constraints that can limit which combinations of responsibilities a user may exercise. NIST’s RBAC overview provides the underlying model.

For product design, use four questions:

“Approvers can approve requests” is incomplete.

“Approvers can approve submitted requests in their assigned departments, within their approval limit, provided they did not submit the request” is a rule that design and engineering can implement together.

Avoid creating a separate role for every department, amount threshold, or ownership exception. Reusable roles can be combined with record attributes and relationships. The implementation may use role-based, attribute-based, or relationship-based controls; the interface still needs to explain the resulting access clearly.

The following matrix describes an illustrative purchase-request product. It is a design example, not a Dworkz client implementation.

The roles are:

• Observer: monitors requests in assigned departments.

• Requester: creates and maintains their own requests.

• Approver: reviews submitted requests in assigned departments.

• Access administrator: manages role assignments and department scope.

All access remains within the active organization. “Assigned departments” means the departments explicitly included in that user’s access.

This model deliberately separates access administration from business approval. A person who manages accounts does not automatically gain permission to approve purchases.

A person may hold more than one role. In this example, applicable grants combine, while organization boundaries and the prohibition on self-approval still apply. A Requester who is also an Approver can create requests and review other people’s requests. They cannot approve their own.

Document this combination rule explicitly. Otherwise, designers may assume the strictest role wins while engineers implement the union of all permissions.

The matrix is also bounded. Exporting, deleting, sharing, and viewing sensitive fields require their own decisions. Permission to view a request should not silently authorize every action available around it.

A permission matrix records policy. An interface specification describes how users experience that policy.

For each meaningful rule, define the visible content, available controls, explanation, and recovery path.

The distinction between the third and fifth rows matters. One action is blocked by workflow state; the other is blocked by a responsibility rule. Sending both users to an administrator would misdiagnose the problem.

View permission should produce a useful screen.

An Observer opening a request might need its purpose, amount, owner, status, and decision history. Present those details as readable content. A page filled with disabled input fields makes information harder to scan and implies that editing is the expected way to use the screen.

Keep text legible. Preserve navigation, filtering, sorting, and links to other records the user may access. Remove editing affordances that add no value.

Be precise about what “view” includes. Access to a request does not necessarily include confidential attachments or every field. Define any narrower permissions before designing the layout.

If a restricted field’s existence may be disclosed, a label such as “Restricted information” can explain the gap. If even its existence is sensitive, omit the field and its value entirely.

Example: An Observer can read a request’s business purpose and status. They cannot open a confidential attachment. The interface either explains the attachment restriction or omits the attachment, according to the disclosure policy.

Never send a protected value to the browser and merely cover it with a visual mask. OWASP recommends enforcing authorization in trusted application layers and checking permissions on every request; hiding a control is not an access boundary. OWASP Authorization Cheat Sheet

“Can edit” rarely means “can edit everything at any time.”

In the example product, Requesters can edit their own requests while those requests are Draft or Returned. Submission locks the details while an Approver reviews them.

That gives the same person three different experiences:

Do not describe a submitted request as “You don’t have permission to edit.” That suggests a role assignment could fix the problem.

Use the actual reason:

This request is being reviewed. Details are locked after submission. If changes are needed, the approver can return it for revision.

If the product supports withdrawal, specify who can withdraw a request and when. Do not add a convenient Withdraw button without defining its effect on pending reviews and notifications.

Also decide which fields become editable after a return. Changing a description may have different consequences from changing the department, requester, or amount.

Approval deserves its own permission and interaction design.

Editing changes the request. Approval records a decision about a particular version of that request. Combining these into a broad “Manage” permission obscures who is accountable for what.

An approval screen should answer:

• What am I approving?

• Which version am I reviewing?

• What changed since the previous submission?

• Is this within my authority?

• What happens after I confirm?

For an eligible Approver, a confirmation might read:

Approve request PR-1048 for $8,400? This records your approval of the current request version and moves it to Approved. Approve request · Cancel

In this example, approval does not initiate payment. If a real product triggers payment, publication, provisioning, or another consequential action, say so explicitly.

For a request above the approver’s limit, explain the route forward:

This request exceeds your approval limit. A reviewer with a higher limit must approve it.

Only show “Route to another approver” if the user has that capability and the workflow supports it.

For someone reviewing their own submission:

Another approver must review this request. You cannot approve requests you submit.

These messages explain the rule without asking users to decode a permission code.

The system also needs to protect against stale decisions. If another person changes or processes the request while the approval screen is open, recheck its status and version before recording approval. Ask the reviewer to inspect the updated request when necessary.

There is no universal rule that unavailable actions should always be hidden or always be disabled. Choose based on relevance, discoverability, and what may safely be disclosed.

A disabled control needs an explanation users can actually reach. Put essential information in visible text or an accessible help element. Do not rely only on a hover tooltip attached to a disabled button.

Keep different causes distinct:

• Permission: “Your role cannot edit requests.”

• Scope: “You don’t have access to this department.”

• Workflow: “This request has already been approved.”

• Validation: “Add a business purpose before submitting.”

• Plan availability: “Custom approval routing is not included in this plan.”

The appropriate next step differs in each case. An upgrade prompt will not resolve a missing role. A permission request will not fix incomplete form data.

Where revealing the specific cause would expose protected information, use a less specific message.

“Access denied” ends the interaction without helping the user recover.

Where policy allows, explain the limitation and offer an appropriate route: return to the request list, switch to an organization the user belongs to, or request a specific access grant.

An access-request flow should identify the capability and scope being requested. “Request permission to edit Marketing requests” is more useful than “Request more access.”

Show where the request goes, whether a reason is required, and what happens after submission. Once sent, display a pending state. Approval of the access request should update the relevant interface.

Offer this path only where access can actually be requested. Do not display it for another organization’s private record or imply that every restriction is negotiable.

Distinguish an empty list from a restricted one as well. “No requests in your assigned departments” communicates the visible scope. “No requests exist” makes a broader claim the application may not be authorized to support.

Permissions affect more than detail pages.

A saved view should preserve filters and presentation preferences; opening it must still respect the viewer’s current access. Sharing a view should not silently grant access to the records behind it.

Search results, autocomplete, dashboard totals, exports, and notifications need their own disclosure rules. A hidden record can still be exposed through a title, count, attachment name, or email preview.

Bulk actions require particular care because selected records may have different eligibility.

Suppose an Approver selects ten visible requests. Six are eligible, two are their own submissions, one exceeds their limit, and one has already been approved.

A useful interface could say:

6 of 10 selected requests can be approved. Two are your submissions, one exceeds your limit, and one is already approved. Review 6 eligible requests

This example assumes those reasons are safe to reveal because the user can already view the records.

Define whether the operation processes eligible records or requires the entire selection to qualify. Never silently drop ineligible records. Show the exact scope before confirmation and the outcome afterward.

If a request changes during processing, report that result separately. The selection summary is a preview, not a guarantee that every action will still be allowed.

Administrators need to understand the consequences of assigning a role.

Replace vague descriptions such as “Full access” with specific summaries:

Approver Can view requests in assigned departments and approve submitted requests within an assigned limit. Cannot edit request details or approve their own submissions.

Show role, scope, and conditions together. An Approver role without a department or approval limit may be incomplete.

Where access comes from multiple sources, explain the effective result:

“Can approve Marketing requests up to $10,000 through the Department Approvers group.”

Before changing a shared role, show who will be affected. Before removing an approver, identify pending work that may need reassignment.

Constrain delegation too. An access administrator should only grant permissions within their authority. Sensitive business-role assignments may require a separate approval policy.

A permission matrix should travel with the interface specification and test scenarios.

For each important capability, document the allowed state, the denied state, and the transition between them.

Test direct links and application requests as well as visible controls. OWASP recommends denying access by default and validating authorization on every request, including requests that bypass the interface.

If a save fails because edit permission changed, preserve unsaved work only where policy still permits it. Revoked viewing access may require clearing protected content rather than keeping a local copy.

Keep the matrix current when workflows change. A new status, sharing feature, or export action can introduce access decisions that the original design never addressed.

A permission model can be technically correct and still create daily confusion.

In usability testing, ask people to explain what they can do before they act:

“Can you change this request?” “Why is approval unavailable?” “What would you do to get access?” “Which records will this bulk action affect?”

Track task completion by role, failed-action reasons, access-related support requests, and delays caused by unclear ownership or review routes.

Do not treat every denied action as a usability failure. Some restrictions are intentional and necessary. Look for cases where users cannot understand the reason or identify the next legitimate step.

The most useful permission matrix connects responsibility to behavior. It tells the team who can act, which records are in scope, what conditions apply, and what the interface should communicate when an action is unavailable.

Start with one important workflow. Define view, edit, and approve separately. Design the restricted states alongside the successful ones. Then verify that the implemented behavior matches the rules.

Dworkz is a San Francisco–based UI/UX design and development firm helping B2B SaaS teams make complex products easier to use. If roles, approvals, and access rules are making everyday work harder, let’s talk about designing a clearer experience.