Who can act for your customer in the portal?

Consider a fictional supplier serving customers with several branches. A buyer orders for two locations. An accounts colleague needs invoices across the organisation. A temporary replacement only needs to follow open requests at one branch. Each may need a personal account, but they do not need identical permissions.

OWASP's authorisation guidance distinguishes establishing identity from deciding whether an action is permitted. It also recommends checking permissions on every request. A successful sign-in therefore does not settle what a person may do for a particular customer or branch.

Make that business context explicit. A role should belong to a defined customer relationship and, where needed, a particular part of it. If someone works for several organisations, make the current organisation clear before they submit an order. An accidental purchase for the wrong branch can create real work even when nobody is trying to misuse the system.

Start with actions that customers and employees recognise. Terms such as administrator or standard user are only useful when their practical meaning is agreed. Does an administrator manage colleagues, see financial information, change an order, or all three?

The table below is an illustrative discussion aid. It is not a universal access policy. Adapt the boundaries to your offer and the responsibilities agreed with each customer.

On a small screen, scroll horizontally to read the full table.

Discuss combinations as well as individual rows. Someone may need invoice access without ordering rights. Managing invitations need not imply access to every commercial detail. Keep the arrangement understandable, but avoid using an unrestricted role as the default answer whenever a genuine exception appears.

At the start of the relationship, identify who can request or manage permissions for the customer. Confirm that appointment through an established contact route. An email address sharing the customer's domain should not, by itself, establish authority to administer the entire account.

Make an invitation specific about its organisation and intended role. Give each person their own account rather than circulating a shared password. An invitation for one location should not silently grant access to every location. Define which roles the customer administrator can assign and which changes require another decision.

Plan for the administrator becoming unavailable. Customer service needs a route for receiving a replacement request and referring it to someone who can verify the relationship. An employee should be able to move the request forward without inventing an identity check or granting unrestricted access under pressure.

The customer's experience matters here. Explain what information is required, who will review it and what happens next. A clear route is more helpful than an unexplained refusal or a broad exception that nobody can later account for.

The UK NCSC's guidance on using SaaS securely covers adding, changing and removing access, including for external users. Where automated lifecycle management is unavailable, it advises reviewing access periodically and removing access that is no longer needed.

Translate that principle into a working agreement with the customer. Who reports a departure, a move to another branch or the end of temporary cover? Who processes the change and confirms completion? Where appropriate, give temporary permissions an end date so that short-term cover does not become a permanent arrangement by accident.

Ask the technical partner what happens to existing sessions and other access mechanisms when rights are withdrawn. Preventing the next sign-in is not a complete explanation. Also distinguish future access from information already downloaded: removing an account does not retrieve copies already held elsewhere. Make the limits understandable when agreeing the process.

When a customer cannot place an order, your colleague needs to understand the cause. Perhaps the wrong branch is selected, approval is pending or ordering authority has not been granted. Give the support team enough context to identify the appropriate next step without exposing information they do not need.

Keep a usable history of permission changes: who changed the authority, what changed and which request supported it. Make that history available to the people responsible for reviewing access. It can help resolve mistakes and explain actions taken on a customer's behalf. Avoid collecting unrelated content simply because a logging facility makes it easy.

A workable arrangement also needs someone available to decide. If ordinary corrections remain unresolved, customers may borrow a colleague's account to get work done. Agree a practical route for urgent assistance that still respects the customer's authority and the boundaries of the service.

Bring together a customer representative, customer service and the technical partner. Walk through a complete ordering journey with agreed test accounts and test data. Confirm that a person can act for branch A while branch B remains outside their authority. Change the role during an existing session and check the next action.

Include document links, exports and confirmations. Hiding a button is not evidence that the underlying action is protected. Ask for demonstrations of expected refusals as well as successful actions. After a refusal, a properly authorised person should still have a clear way to complete the work.

Begin with one complete journey covering invitation, everyday use, changed responsibility and departure. Our guide to customer self-service with personal support addresses the broader service experience. Through customer and partner portals, IndustrylinQ connects those working agreements with product design, permissions and implementation. The aim is authority that people can understand and use throughout the relationship.