Customer portal roles and permissions: who may use which record?

Separate signing in from permission

Signing in can establish which account a person uses. It does not decide that the account may open a particular record. Describe identity and the relationship granting access separately. An invited customer contact might see requests belonging only to the organisation named in the invitation, while another relationship has its own selection. An account identifier is not a complete access decision.

OWASP describes default denial and permission checks on every relevant request. Translate that narrow technical principle into your portal’s own rules. A hidden button, for example, is not an acceptance criterion proving that an operation is prevented. Assess what the application actually accepts when somebody addresses a record or action directly instead of following the interface’s normal sequence.

OWASP: Authorization Cheat Sheet ↗

Create a matrix of relationships and operations

Begin with recognisable roles: customer contact, customer administrator, case handler and internal administrator. Identify the organisations and records associated with each. Separate viewing, supplementing, downloading, inviting and confirming. A person may have broader responsibility in one organisation than another. A global job title alone may therefore be insufficient to determine which information should be selected for a request.

Work through a normal enquiry first. A contact supplements their requests, a customer administrator invites colleagues within the same organisation, and a handler assesses assigned cases. Then consider an excluded case: a handler for another region may not open the record. The matrix becomes a collection of concrete decisions instead of an abstract grid of check marks whose practical meaning remains unclear.

Limit information within a record as well

Access to an enquiry need not mean access to every field. Internal notes, commercial comments and customer-facing progress can have different audiences. Decide which information each role needs for its task and what remains internal. Make the distinction visible in sample records so users can recognise what belongs in the portal and what should remain in another working context.

Include derived views such as search results, counts, exports and notifications. They may reveal information absent from the detail page. An overview hiding a customer name while exposing a recognisable subject can still make the boundary ambiguous. Examine different presentations of the same record in the design. The permissions plan should follow the information rather than only the screen where somebody expects to see it.

If the portal also searches company documents, the search layer must enforce the same access boundaries: RAG access control: who may retrieve which company information?.

Design invitation and organisation selection explicitly

An invitation should identify the organisation and responsibility being granted. A customer administrator should not silently grant access to other organisations because an existing email address can hold several roles. Describe who can invite, how acceptance is associated with a relationship and what happens when an invitation expires or is withdrawn. Keep those events distinguishable from an account merely existing in the application.

A user with several relationships needs to understand the context in which they are working. Show the relevant organisation and make the information selection follow a context change. Test an operation prepared before the person switches organisation. The application needs a way to establish which relationship applies to the operation; the most recently displayed screen title should not silently make that decision on its behalf.

Treat files as separate access points

A download may be opened outside the normal record page or used again later. Define how the application establishes whether the person may obtain the document at that moment. Possessing a file reference differs from having a current business relationship with its record. Investigate what happens after account access or organisation membership is removed, rather than assuming the original page controls every future retrieval.

Use two organisations with similar file names in the trial. Demonstrate that an authorised person can retrieve their own document and that the same route does not return the other organisation’s file. Include a replaced or revised document so the intended version is clear. A correct listing alone does not establish that the underlying download boundary has been implemented appropriately for the agreed access model.

Give editing and confirmation distinct meanings

Permission to supplement information need not include permission to confirm a final arrangement. Describe the consequence of each operation. Correcting an address, accepting a proposal and completing an internal task are different events. Determine what the person must see and whether review is needed again when content changes after a previous check. The interface should not obscure those distinctions behind one generic save operation.

In the fictional portal, a contact submits a draft while a customer administrator confirms a particular assignment. Retain which content was reviewed and which valid role caused the transition. The implementation should prevent a subsequently changed version from being executed as though it had already been approved. For consequential operations, discuss explicitly how the relationship between reviewed content and execution can be demonstrated in the actual application.

OWASP: Transaction Authorization Cheat Sheet ↗

Prepare departure, delegation and revocation

A useful plan also covers changing access. An employee leaves, a customer contact changes responsibilities or a case moves to another handler. Describe access that ends, pending actions requiring review and the person taking over. Blocking an account does not explain how the unfinished business process continues or which decisions someone else is allowed to make afterwards.

Distinguish historical evidence from current authority. You may need to understand who made an earlier decision without giving that person permanent access. Include existing sessions, shared references and scheduled actions when investigating revocation. The technical approach depends on the systems involved; the intended business boundary should remain explicit before any implementation is chosen. Record uncertainty instead of treating revocation as a single checkbox with identical meaning everywhere.

Make access investigation usable for administrators

When a user cannot open a record, an authorised operator needs to investigate why. Use understandable reasons such as missing organisation membership, an expired invitation or an unassigned case. Give support enough information to determine a next step without automatically making all case contents available to everyone who can read an error notification. Operational visibility and customer-record access can have different boundaries.

Decide who may approve an access change and how it is recorded. Someone helping restore account sign-in need not be able to assign customer relationships. Work through an urgent request. A recognisable escalation path is more manageable than ad hoc administration where every unclear block is resolved by granting a much broader role. The plan should explain the route staff can use when ordinary access is insufficient.

Review a bounded but meaningful set of cases

For every important role, prepare an allowed and a refused operation. Include direct record references, downloads and requests following a role change. Check not just the message shown but that a forbidden change was not stored and restricted content was not returned. Keep fictional accounts, records and expected outcomes with the relevant version so later changes can be assessed against the same intended boundary.

Repeat relevant cases when adding a role, organisation relationship or information view. The trial set should grow with meaningful access boundaries rather than every cosmetic adjustment. Ask the process owner whether expected access fits the work and the developer to explain where it is enforced. Combining business decisions with demonstrable application behaviour makes a permissions plan useful for implementation, acceptance and eventual handover to another responsible person.

Turn the explanation into a project decision

Record your assumptions, unknowns and acceptance checks in the matching tool. Use the service guides to discuss delivery and scope.

• Custom software development ↗
• Customer portal development ↗

Questions about this topic

Continue with a related question