Who should be able to see each document in a customer portal?
Quotes, technical drawings and delivery records may share one customer portal without sharing the same audience. Before designing screens, break “customers sign in and see their files” into smaller decisions. Which company does the person represent? What task are they allowed to perform? Which document does that permission cover? All companies and roles here are illustrative, not records from a client portal.
Start with tasks instead of navigation
Describe three jobs at the first meeting: a purchasing contact downloads a quote, a technician opens an approved drawing, and a company administrator invites a colleague. These tasks have different boundaries. Giving everyone administrator access may feel convenient initially, but makes later reviews harder. Keep the first permission table small enough for the content owner and development team to review together.
Separate identity from permission
The OWASP Authorization Cheat Sheet distinguishes authentication from access decisions. It recommends least privilege, denying unspecified access by default and checking permissions on every request. Hiding a navigation link does not replace server-side enforcement. The decision must include the requested resource and its relationship to the user, not merely a role name.
Put company boundaries in the matrix
In our example, Company A’s purchaser may view Company A’s quote but not Company B’s. A technician may receive only approved drawings. Inviting another user is a separate capability. Add columns for viewing documents, uploading files and managing members. This makes it harder to accidentally treat all operations as consequences of one broad “customer” role. Review each allowed combination with the business owner.
Describe exceptions explicitly
An external specialist who needs one project should not silently receive general company membership. Record the project, document set and intended working period, together with the person responsible for reviewing access. If someone represents two companies, show the active company clearly. These interface decisions help explain the boundary, but still require enforcement on the server. The label alone is not the permission check.
Test the refusal as well as the success
A permitted user opening a file is only one acceptance case. In a test environment, use fictional Company A and B accounts to verify that a known link to the other company’s document is rejected. Do not use private customer documents as fixtures. A refusal screen should avoid exposing unnecessary document details and provide a clear route back to the person’s own workspace.
Plan for people changing jobs
Record what happens when a colleague leaves or changes responsibilities. Permission removal, pending invitations and existing shared links deserve separate review. When adding a new role, check that existing roles do not gain broader access unintentionally. Name the person who owns the permission matrix after launch. The portal needs a manageable update process, not just a correct opening-day staff list.
Make this part of the project scope
Our accessible sign-in guide covers entering credentials; this article defines boundaries after entry. Include the role matrix, document scope and refusal tests in the website project brief. A matrix is not a security audit or a promise of complete protection. It is a concrete agreement about intended behaviour that can guide implementation and review.
Frequently asked questions
Are hidden menu items sufficient?
No. The server must check permission when a document is requested directly. Navigation visibility is only an interface choice.
Does a small portal need a permission matrix?
If tasks or document scopes differ, a small table helps. Start with necessary distinctions rather than creating speculative roles.