Map accounts, users and roles
List the organisations or accounts the portal serves, then describe which users belong to each. A person who can view an invoice may not be allowed to change contact details or approve a request. An internal support role may need different access from a customer administrator.
Record these differences before designing the screens. Where users can belong to multiple accounts, define how the selected account is established and how every request is tied to it.
Check the record, not just the menu
Hiding a menu item does not establish permission to access the underlying data. Authorisation belongs on the server and needs to be checked on each request, including downloads and background actions. The default should be to deny an action until the required permission is established.
For example, changing an invoice identifier in a URL must not expose another account’s document. Test with more than one customer account and with different roles, so successful login is not mistaken for correct ownership isolation.
Keep the customer journey understandable
Decide what users see when a record is unavailable, a request needs approval or an external system is delayed. Clear status and confirmation messages help people distinguish a pending action from a completed one.
Include the route to human support, the account-recovery process and the audit history needed by your team. A portal should reduce avoidable administration while keeping responsibilities visible.