Client Portal Requirements: Define the Work Before the Screens

A client portal requirements checklist should define who can do what, with which information and under which conditions. Screens come after those decisions. A dashboard, document area and message feature may look complete while leaving unanswered whether one client can see another client's files or who must act when a request is rejected.

Begin with one complete service journey. Identify the client action, staff response, required records and final outcome. Then add permissions, exceptions and operational responsibilities. This produces a scope that can be designed and tested, rather than a list of interface features whose relationships are still unclear.

Define the Users and the Work They Need to Complete

List client users, client account owners, internal staff and administrators. Describe their actual jobs instead of assuming each group needs a generic dashboard. A client may need to submit information and check progress; a staff member may need to review it, request a correction and record a decision.

Identify the primary service boundary. Is the portal for document exchange, project requests, account reporting or several connected workflows? Choose the first-release outcome deliberately. A portal that offers many incomplete features can be harder to use than one that reliably completes a focused task.

Write a Normal Journey in Plain Language

For a hypothetical professional-services portal, a client submits a request with a supporting document. The assigned team reviews it, asks for clarification if necessary and provides a final response. The client can see the current state and the relevant history, but not another organisation's requests.

That short description already raises useful requirements: assignment, document access, clarification, status history and account separation. Record those before drawing the dashboard. The example is illustrative; your actual workflow should be confirmed with the people responsible for delivering the service.

Model Organisations, Membership and Permissions

Decide whether an account represents a person, a client organisation or both. A consultant may belong to several client organisations, while a client employee may need access to only one project. Make these relationships explicit rather than using a single broad role to represent every situation.

Create an action matrix covering viewing, creating, changing, approving and removing relevant records. Specify the scope of each permission. “Can view documents” is incomplete without saying which organisation, project or request the documents belong to.

Illustrative action	Client member	Client account owner	Assigned staff	Platform administrator
Submit a request	Within permitted account scope	Within permitted account scope	On behalf only if approved	Not automatically required
View a request	According to membership and assignment	According to account policy	Assigned service scope	Limited support access by policy
Invite a colleague	Usually restricted	If account policy permits	Not ordinarily a client action	Controlled administrative route
Approve a service response	Only if explicitly authorised	If designated approver	According to staff workflow	Not implied by technical access
Remove account access	No general permission	Within delegated authority	Escalation route	Audited administrative action

This matrix is a starting example, not a recommended universal permission policy. Complete it with your own resources and relationships, then test both allowed and denied actions against the final implementation.

Treat Login and Authorisation as Separate Requirements

OWASP's authorisation guidance makes the distinction between establishing identity and permitting an action. A portal must enforce the relevant resource permissions, not merely hide controls from the interface. Review direct requests and file access as well as visible navigation.

Use denied-access scenarios in acceptance. A user from Client A should not retrieve Client B's request by following a copied link. A former member should not retain access through an old session or document URL. Conduct these tests only in an authorised environment with safe records.

Specify Invitations, Departures and Ownership Changes

Define who may invite users, how an invitation is accepted and what happens if it expires or reaches the wrong person. Clarify whether membership is automatic, approved or tied to a verified business process. Avoid treating possession of an email address as permission to join any client account.

Plan for departure before launch. Removing a person may require revoking access, transferring open tasks and retaining a truthful activity history. Do not erase the operational record simply to remove login rights. Agree retention and privacy requirements with the responsible business advisers where necessary.

If a client account owner leaves, another authorised person needs a recovery route. Define how support verifies the request and records the transfer. An undocumented manual database edit should not be the normal way to restore account administration.

Define Request States and Valid Transitions

Write down the states a request can occupy, such as draft, submitted, under review, clarification needed and completed. Explain who may move it between states and what information is required. Avoid status labels that mean different things to clients and staff.

For each transition, define side effects. Does submitting lock part of the form? Does requesting clarification notify the client? Can a completed request reopen, and who may authorise that? These rules determine the application behaviour and are easier to review before implementation.

Include Incomplete and Conflicting Actions

Consider a client editing while staff review the same record. Decide whether changes are versioned, blocked or clearly reconciled. A silent overwrite can lose an approved decision or make the visible history misleading.

Define what happens when an upload or submission is interrupted. The user should know whether the action completed and how to resume safely. Avoid a success message before the system has retained the necessary record, and avoid requiring repeated submission when the first attempt may already exist.

Treat Documents as Protected Records, Not Just Attachments

Specify accepted file types, size limits, storage, retention and access behaviour. Decide whether files require review before other users can download them. Establish how a replacement version relates to the original and whether staff need an audit trail of changes.

OWASP's file-upload guidance describes layered controls rather than trusting a filename or browser-supplied type. The implementation should validate uploads and protect retrieval according to the portal's risk. A visible upload button and a successful file transfer are not a complete security review.

Test a permitted file, a disallowed type, an oversized file and a safely simulated processing failure. Confirm clear messages and appropriate cleanup of incomplete uploads. Use approved security testing for deeper cases; do not introduce harmful files into a live client system.

Make Notifications Useful and Safe

Choose which events deserve immediate notification and which can remain in the portal or a digest. Every internal status change does not necessarily require an email. Excessive messages can make genuinely important requests harder to notice.

State what information an email may contain. Sensitive details may belong behind authenticated access rather than in the message body or attachment. Links should take the user to the correct context after login without bypassing the record's permission checks.

Define delivery failure handling. If an invitation or urgent action notice does not reach its recipient, staff need a way to identify and resolve it. A notification service accepting a message is not proof that a person received or acted on it.

Assign Data and Integration Ownership

Identify whether the portal or another system owns client details, requests, documents and status. Define which changes can flow in each direction and how conflicts are resolved. Avoid two systems silently overwriting one another because both are treated as authoritative.

For integrations, record identifiers, expected delay, retries and recovery. A portal may display a request successfully while a downstream service has rejected it. The user-facing state should reflect the actual workflow and the support team should be able to trace the handoff.

If software procurement is still open, use the build-versus-buy decision framework with these requirements. A product demonstration should prove your roles and exception cases, not merely show that it includes a document area.

Define Support, Audit and Recovery Responsibilities

Record which actions need an audit history and who may read it. Capture enough context to investigate changes without storing secrets or unnecessary personal information. Agree how records are corrected and how support access is controlled.

Include backup and restoration expectations for the database and documents together. A restored request with missing files is not a complete recovery. Test the relationship between records and stored assets in an isolated environment, and document the responsible operator.

Plan routine administration: access reviews, account closure, failed-job monitoring and dependency updates. These are part of the portal's operating model. A project that ends at interface delivery leaves important ownership unresolved.

Write Acceptance Scenarios Before Design Approval

Turn the requirements into normal, denied and exception journeys. A normal test demonstrates a client submitting a request and receiving the correct response. A denied test demonstrates that an unrelated user cannot access it. An exception test demonstrates how an interrupted upload or rejected integration is recovered.

Scenario	Expected evidence
Permitted client submits a complete request	One traceable record in the correct account
Another client opens its copied link	No protected information disclosed
Staff request clarification	Correct state, visible instruction and appropriate notification
Client employee loses membership	Access revoked while necessary history remains
Document processing fails	Clear status and safe retry without duplicate confusion
Backup is restored in isolation	Requests, permissions and files remain consistent

Use these scenarios during design review as well as final QA. They reveal missing screens, unclear wording and unsupported states early. Include mobile and keyboard use, because a complete workflow must remain usable outside the designer's preferred desktop view.

Bring the role matrix, state model and acceptance scenarios into web application discovery. They give the team a concrete definition of the portal and protect the first release from expanding into unrelated features while essential access and recovery rules remain unfinished.