Planning Client Portal Roles and Permissions

1. Start With Actions, Not Role Names

A common mistake is to define three roles — Client, Staff, and Admin — and assume the permission model is finished.

Those names do not explain what anyone can actually do.

Instead, begin with actions.

For one portal workflow, the important actions might include:

• view a request;
• create a request;
• edit submitted information;
• upload a file;
• download a file;
• respond to a staff question;
• change status;
• approve a request;
• assign a staff member;
• add an internal note;
• manage user access.

Then decide which roles are allowed to perform each action.

2. An Illustrative Three-Role Model

Consider a portal supporting one defined client request workflow.

Client User

Possible permitted actions:

• create a new request;
• view permitted requests for the organization;
• review current status;
• upload requested documents;
• respond to questions;
• update selected fields while the workflow allows it.

Possible restrictions:

• cannot see another organization's requests;
• cannot view internal staff notes;
• cannot directly change internal workflow status;
• cannot assign staff;
• cannot manage system-wide configuration.

Staff User

Possible permitted actions:

• view requests assigned or available to staff;
• review client submissions;
• request missing information;
• add internal notes;
• update allowed workflow states;
• review uploaded documents;
• complete defined staff actions.

Possible restrictions:

• cannot change administrative settings;
• cannot grant themselves broader access;
• may not be permitted to manage other staff accounts.

Administrator

Possible actions could include:

• manage authorized users;
• assign roles;
• maintain selected configuration;
• oversee access changes.

An administrator does not automatically need unrestricted access to every business action.

This example uses three roles because it demonstrates the planning method clearly. A different portal may legitimately require fewer or more roles.

3. Separate Role From Record Ownership

Role and record ownership are different concepts.

A user may have the role Client User, but that alone should not determine which customer records are visible.

The system also needs a rule describing which records belong to that user or organization.

For example:

A client user may view requests associated with the user's authorized organization.

This is stronger than:

Clients can view requests.

The first statement defines a boundary. The second does not.

4. Define the Customer Boundary Explicitly

Customer data separation should be written as a requirement.

A client user associated with Organization A must not be able to retrieve a request belonging only to Organization B.

That requirement applies whether the user attempts access through normal navigation, search, a copied link, a changed URL, or a direct request to an application endpoint.

The exact technical implementation belongs to the development design. But the business requirement should exist before that design is created.

5. Build a Role-and-Action Matrix

The point is not that every portal should use these exact permissions. The point is to force each capability to have an explicit owner.

6. Define Create, View, Edit, and Approve Separately

“Access” is too broad.

A person may be allowed to view a record without being allowed to edit it. A person may be able to edit selected fields without being able to approve the record.

Treat actions separately:

• View — Can the role retrieve and display the record?
• Create — Can the role create a new record?
• Edit — Which fields can be changed, and at what workflow stages?
• Approve — Can the role make a decision that moves the workflow forward?
• Delete or cancel — Is removal allowed, or should the system preserve the record and change its status instead?
• Assign — Can the role change the staff member responsible for the work?

7. Permissions Can Depend on Workflow State

Access is not always static.

Draft

• client can edit;
• client can upload;
• client can submit.

Under Review

• client can view;
• editing primary submitted fields may be restricted;
• staff can review.

Waiting on Client

• client can provide requested information;
• staff may wait for response.

Completed

• both sides may retain appropriate read access;
• normal edits are disabled.

The terminology matters less than documenting the rule.

8. Plan File Permissions Separately

For every file type, consider:

• who uploads it;
• who can download it;
• which record it belongs to;
• whether it is client-visible;
• whether staff-only files exist;
• whether files can be replaced;
• whether old versions remain available.

Do not leave file visibility implicit.

9. Internal Notes Should Be Explicitly Internal

If the portal includes internal notes, define them as a separate data type or visibility class rather than relying on staff to remember what not to write in a client-visible field.

An acceptance requirement might say:

A client user cannot retrieve or display staff-only notes associated with the request.

This is a requirement, not a claim about a particular security implementation.

10. Test What Users Must Not Be Able to Do

If the expected test is:

Client A can open Client A's request.

also test:

Client A cannot open Client B's request.

Other examples:

• client cannot add an internal note;
• staff user without admin rights cannot change another user's role;
• a disabled account cannot continue using authenticated portal functionality;
• a user cannot edit a record after the workflow state makes it read-only;
• a user cannot access a file attached only to an unauthorized record.

11. Do Not Rely Only on Hidden Buttons

For planning purposes, write:

A Client User is not authorized to change the internal status of a request.

Do not write only:

The status button is hidden for clients.

The first describes the rule. The second describes one possible interface behavior.

12. Think About Account Lifecycle

A useful portal specification should answer:

• How is a new user invited?
• Who approves access?
• How is the user associated with the correct organization?
• Can an organization have multiple users?
• Who can remove a user?
• What happens when an employee leaves the client organization?
• What happens when a staff member changes responsibilities?
• When should sessions or access be revoked?

Even a small portal benefits from a defined account lifecycle.

13. Avoid Shared Accounts

If several people share the same login, the application cannot easily distinguish which person performed an action.

That can complicate approvals, status changes, corrections, support, access revocation, and operational history.

If accountability matters to the workflow, define users individually and associate them with the appropriate organization or role.

14. Decide What Needs an Audit History

Examples include:

• request submitted;
• status changed;
• document received;
• approval recorded;
• staff assignment changed;
• client access removed.

Before adding logging everywhere, identify which actions the business needs to reconstruct later.

Do not label ordinary application history as regulatory compliance unless a specific compliance requirement has actually been established.

15. Convert Permission Requirements Into Acceptance Criteria

Requirement

Client users may access only requests belonging to their authorized organization.

Acceptance checks

• Client A can open Request A belonging to Organization A.
• Client A cannot retrieve Request B belonging only to Organization B.
• Request B does not appear in Client A's search or list views.
• A direct navigation attempt does not expose Request B.

Another example:

Requirement

Only authorized staff may mark a request completed.

Acceptance checks

• an authorized staff user can complete an eligible request;
• a client user cannot perform the same action;
• a staff user without the required permission cannot perform the action;
• an ineligible workflow state prevents completion until required conditions are satisfied.

16. Keep the Matrix Small Enough to Understand

Start with the primary workflow.

Identify:

• core roles;
• core records;
• significant actions;
• important visibility boundaries.

Then add complexity only where the workflow requires it.

The objective is not maximum configurability. It is predictable access.

17. A Practical Planning Worksheet

Roles

Role: Client User Purpose: ____________________ Organization boundary: ____________________

Role: Staff User Purpose: ____________________ Operational boundary: ____________________

Role: Administrator Purpose: ____________________ Administrative boundary: ____________________

Primary record

Record type: ____________________ Record owner: ____________________ Client visibility rule: ____________________ Staff visibility rule: ____________________

Actions

Who can create? ____________________ Who can view? ____________________ Who can edit? ____________________ Who can approve? ____________________ Who can change status? ____________________ Who can upload files? ____________________ Who can view internal files? ____________________ Who can manage accounts? ____________________

Negative tests

A client must NOT be able to: ____________________ A normal staff user must NOT be able to: ____________________ A disabled user must NOT be able to: ____________________ A user from another organization must NOT be able to: ____________________

Account lifecycle

Who invites users? ____________________ Who changes roles? ____________________ Who revokes access? ____________________ What happens when access ends? ____________________

18. How This Fits With Portal Requirements Planning

Roles and permissions are only one part of portal planning.

They should be defined alongside the business process, records, screens, integrations, status transitions, documents, exceptions, and acceptance criteria.

If those broader requirements are not yet defined, start with the Client Portal Requirements Checklist before building a detailed access matrix.

19. Relating Permissions to a Fixed-Scope Portal

The current Northbridge Client Operations Portal is designed around one defined business process with a client-facing workspace and a connected staff workspace, within published limits that include up to three defined roles.

That does not mean every possible three-role permission model automatically fits.

The required screens, integrations, workflow rules, record visibility, and actions still need to fit the published package.

A requirement involving many organizations, nested account hierarchies, dozens of permission combinations, extensive delegated administration, or broader identity-management requirements may call for a different scope.

Use the role count as one boundary, not as a substitute for requirements analysis.

Permissions Should Be Testable Before They Are Trusted

A portal permission model should answer more than “Who has an account?”

It should answer:

• what each role can see;
• what each role can change;
• which records belong to which users;
• how client organizations are separated;
• what actions are prohibited;
• how access changes over time;
• how the team will verify those rules.

For a broader planning process, start with the Client Portal Requirements Checklist, review the illustrative Client and Partner Portal solution pattern, and compare the resulting requirements with the published Client Operations Portal scope.

Related Northbridge resources: internal tools and business software development.