A customer portal is a controlled place where customers complete defined self-service tasks. Plan it through 5 checks: useful tasks, identity, record access, task completion and support ownership. A login screen is only the entrance; the portal must also prevent customers from seeing or changing records outside their authority.
Which tasks justify a customer portal?
Choose a task customers genuinely need to repeat: viewing an order, supplying an approved document, checking a request or updating permitted details. Define the starting information, the action and the confirmation. A portal that merely reproduces a brochure behind a password creates an access burden without providing self-service value. Begin with a coherent journey rather than a long menu of possible features.
Compare a portal with a secure form, a shared document route and a staff-assisted process. A portal may suit continuing access to a customer-specific record. A form may suit a single submission without an ongoing account. The right choice depends on the task, information sensitivity and maintenance responsibility. This comparison is a planning framework, not a claim that a particular product implements every option.
Separate identity from permission. The OWASP authorisation guidance distinguishes authentication from authorisation. Knowing who signed in does not establish which customer organisation or records they may access. Write those relationships explicitly. If a customer works for several organisations, the design needs a deliberate way to choose the relevant context without accidentally combining their information.
Define permissions for actions as well as viewing. A person may be allowed to read an invoice but not change the billing identity, or submit a request but not approve it. Avoid a single vague customer role when the workflow contains distinct responsibilities. Keep the rule readable by the business owner, then ask the implementation team to demonstrate how it is enforced.
Use fictional organisations to test separation. Create a permitted record and a similar record belonging to another customer. Attempt the authorised action, then attempt access to the other record through the available interface and controlled request tests. Only perform these tests in an authorised environment. A hidden menu item does not establish that the underlying request rejects unauthorised access.
How do authentication and access scope shape acceptance?
Include files and exports in the boundary. OWASP discusses access checks on static resources as well as application actions. A portal page can be correctly restricted while an attached document remains accessible through a copied link. Ask how the proposed implementation protects downloads and whether access changes affect existing links. Do not assume that a complicated file name supplies an authorisation control.
Design clear completion evidence. When a customer uploads a document or changes a detail, show the accepted result and the next state. If staff approval is required, say pending rather than complete. Record the submission reference and the responsible queue. This prevents customers from interpreting a successful upload as acceptance of the underlying business request or approval of a document’s contents.
Plan access removal and organisational change. A former employee, a changed customer administrator or an ended contract should trigger a defined permission review. Demonstrate removal using a test identity and inspect active sessions or retained links within the authorised scope. Keep the business owner responsible for deciding who should retain access; the technical mechanism cannot infer every organisational change automatically.
Make failure states useful without revealing private information. A customer should understand whether a task failed and how to get help, but the message should not expose another customer’s details or internal access rules. OWASP recommends safe failure and appropriate logging. Retain enough controlled evidence for investigation while avoiding unnecessary sensitive content in routine logs or support messages.
Test the complete self-service journey with the intended audience. Include first access, a normal task, an invalid input, a permission denial and a request for help. Observe whether the customer can understand the status without a staff member translating the interface. A portal should reduce avoidable handovers while keeping genuine exceptions owned, rather than moving every difficulty behind an inaccessible account screen.
Add a delegated-user exercise to the portal review. Give a fictional customer administrator permission to invite a colleague, if that is part of the proposed scope. Check which organisation the colleague joins and which records become visible. Then remove the colleague and inspect the same task and download routes again. If invitations are outside scope, record that boundary and show the supported staff-assisted route instead. Do not improvise an administrator capability during the demonstration. This scenario tests a relationship change rather than only a static permission, which matters because customer organisations and their representatives can change while the underlying business records remain in the portal.
Keep account recovery and sensitive changes in the portal acceptance plan. OWASP’s authentication guidance recommends reauthentication for sensitive features such as changing a password or email address. For the fictional customer, specify the required identity check before changing a recovery destination, then separately check permission to alter the organisation’s records. A valid identity check must not silently grant access to another customer’s documents.
Decision worksheet
Original contribution: a portal task-and-boundary card. For a fictional document request, name the customer organisation, the person permitted to submit, the staff member permitted to approve and the document each may access. Write the expected states from requested through submitted to approved or returned. Test a second customer attempting the same link and a former employee whose access has been removed. Record the observed result for the page, the underlying action and the download independently. This exposes gaps that a successful login demonstration cannot reveal.
| Checkpoint | Evidence to retain | Decision or corrective action |
|---|---|---|
| Useful task | Customer goal and completion evidence | Choose the smallest coherent journey |
| Identity | Account and customer-organisation relationship | Resolve ambiguous affiliation |
| Access scope | View, change and download rules | Test permitted and denied cases |
| Task state | Submission reference and next owner | Distinguish pending from approved |
| Lifecycle | Removal and support procedures | Retest access after role changes |
Accept the portal only when task evidence and access evidence agree. A usable interface with an excessive permission scope is unsafe, while a secure interface that leaves every task unclear does not fulfil the customer need. Keep both findings in the acceptance record. An external product demonstration should use the proposed configuration, not a vendor account with unrestricted administrator access.
See web development for delivery scope and business email for communication dependencies. To discuss a portal, get started with a fictional task and boundary card. Do not include live customer records or credentials in the initial enquiry.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.