A customer portal's most important design question is often who may see or change each record. The dashboard layout comes later. A polished interface cannot compensate for an unclear boundary between customers, teams and administrators.
Start the permission model with concrete tasks and record ownership. Then make the application enforce those decisions wherever data can be read or changed, not only in the visible navigation.
Describe access in business language
List the roles people actually perform. A customer may view their organisation's projects, a finance contact may access invoices and a staff member may manage delivery. These responsibilities can overlap without being identical.
For each action, name the relevant scope. “Can view projects” is incomplete if it does not say which organisation's projects. “Can invite users” also needs to say which roles can be granted and who can remove access later.
For a hypothetical multi-company portal, a consultant might belong to two customer organisations. The interface should make the active organisation clear, while the server checks access to each requested record independently of that display choice.
Check every route to the data
Hiding a button improves the interface but does not enforce a permission. Requests can reach an endpoint directly, and identifiers can be changed. Apply authorisation at the application boundary where records are retrieved or modified.
Include downloads, exports, search results and background jobs in the review. An otherwise careful portal can leak information through a report that uses a broader query than the page it came from.
Avoid deriving trust from an organisation identifier supplied by the browser. Resolve the user's permitted scope on the server and verify the target record belongs within it.
Design access changes deliberately
People join teams, leave companies and change responsibilities. Invitations, role changes and account removal need a defined process. Decide who can initiate them and what happens to existing sessions or pending work when access changes.
Support staff may need to investigate customer problems. Give that access an explicit scope and record its use where appropriate, rather than making unrestricted administrative access the routine support path.
Keep error responses helpful without revealing records the user is not entitled to know about. The correct behaviour depends on the application, but it should be chosen consistently rather than varying between endpoints by accident.
Test the boundaries with paired accounts
Create test users in separate organisations and run the same actions with each. Try opening a record by a copied URL, requesting an export and modifying a request identifier. Confirm that the server denies access outside the permitted scope.
Then test the intended overlaps: a user with two memberships, a read-only role and a recently removed member. These cases show whether the model reflects the business rather than a single-user demonstration.
Document the permission matrix with the acceptance criteria. It should be reviewable by the people responsible for the customer relationship as well as the developers. Our bespoke portal development treats those access boundaries as core product behaviour, so the dashboard is built on a clear account of who is allowed to do what.