“We need a portal where customers sign in and track requests.” This sounds sufficient for a proposal, yet leaves major decisions to the developer: does an account represent a person or company? Who can view documents? Which status is authoritative when employees use another system? Start with one service journey and identify who owns each step.
A customer portal is a shared workspace with boundaries. Defining it requires more than copying the staff dashboard and hiding buttons. Your brief should make those boundaries understandable and testable, explaining what the supplier will implement and what remains in existing procedures. That lets you compare scopes beyond page counts.
Choose a request both sides can complete
Consider a fictional event-equipment rental company. The customer reviews a preparation proposal, uploads approval and follows delivery arrangements, while an employee confirms availability and records the final document. This illustration describes neither a completed project nor a universal commercial policy. The portal should clarify this task rather than manage the entire business immediately.
Write its start, finish and intermediate decisions. Does requesting a new date immediately change the booking or create a proposal awaiting review? Can customers cancel during preparation? Who explains rejection? “Depending on permissions” is insufficient until you name the role, condition and result visible to the user.
A scope card for one journey
| Journey component | Decision to record | Acceptance evidence |
|---|---|---|
| Customer account. | Organization, members and the role allowed to invite or remove them. | Two members see the agreed boundaries within their organization. |
| Change request. | Editable fields and states preventing changes. | A saved proposal does not become an approved date without required review. |
| Document. | Version source, readers and replacement behavior. | The intended version opens without exposing another organization's document. |
| Request status. | The authoritative system and known last-update time. | Integration failure appears as an update problem, not a new fulfillment state. |
Add an operational owner, data source and deferred work to each row. This is not a ready-made specification for every portal. Remove documents if unnecessary or add another approval when the workflow genuinely requires one. Each addition needs an explanation of its effect on both parties, beyond a screen name.
Separate organization membership from record ownership
One representative might manage requests for two organizations, and a customer's employee might change roles. Discuss access removal and what happens to existing requests. An email domain alone should not establish that everyone using it can view every document. The service owner needs to define this business relationship.
OWASP guidance emphasizes checking authorization on every request and applying least privilege. Include server-side checks connecting users to requests and documents in the proposal; hiding a link does not demonstrate protection. Citing this guidance does not establish certification or completion of an independent security assessment.
Two test customers reveal more than one demo account
Prepare two test organizations with fictional documents. Open an allowed request, then use the same account to attempt access to the other organization's request and file through direct links in an authorized test environment. Access should be denied without exposing content. OWASP's IDOR guidance explains that hard-to-guess identifiers do not replace authorization.
Repeat after removing membership and with a role allowed to read but not approve. Record expected and observed results and an owner for each gap. These acceptance samples do not replace broader security review, and attempts against real customer accounts should not be used to demonstrate the concept.
A notification should not become the source of truth
A scheduling message may arrive after an approved status has changed. Define what the portal displays, whether notifications lead to the current record and how customers question discrepancies. If an external system fails, show the last confirmed information and its freshness limits instead of presenting stale data as live.
The website versus web application guide addresses project type, while this article scopes the portal itself. Send the card and test-organization journey when discussing web application development with Nextwave, requesting clear pricing for the chosen states, roles, integrations and operations.
Authorization references and example limits
OWASP references on authorization and preventing unauthorized record access were opened on 4 November 2026. The card and rental example are original buying guidance. AI assisted preparation, with information and translation review, without customer-experience or security-certification claims.
