Client portal requirements checklist and worksheet

A client portal is an authenticated workspace where clients exchange information and complete defined tasks with a business.

Start with the work clients need to complete

Write one workflow before listing screens: a client supplies a document, submits it for review, and checks its status; an assigned staff member accepts it or requests a correction. Describe the starting information, the finished record, and who makes each decision. Specify whether clients act as individuals, representatives of organizations, or members of several organizations.

Download the client portal requirements worksheet, available without an email gate. It contains blank workflow, record, permission, scenario, integration, and ownership records, followed by a fictional example. Start with one important workflow and expand from there. Broader software planning topics are collected in Wavelength's Learn library.

For each record, identify its client owner, sensitivity, editable fields, and retention decision. Separate viewing a document from approving it. Someone who can upload evidence may have no authority to accept the submission. Write exclusions too: for example, billing and electronic signatures might stay in existing systems during the first release.

Make client portal requirements specific about access

Wavelength’s Client Portal Requirements Worksheet organizes each permission as role × client relationship × record × action. This is our planning method; OWASP supplies the authorization principles below. A role describes the job; the relationship establishes which client that job concerns. Add conditions such as active membership, staff assignment, or submission state. One row should describe one action and its expected decision.

OWASP's authorization guidance recommends least privilege, denial by default, and checking permissions on every request. Apply those principles when specifying downloads, exports, and background actions as well as ordinary page views. Hiding a button is insufficient evidence that the underlying action is denied.

In a portal serving several client organizations, each organization is called a tenant. OWASP’s multi-tenant guidance explains that a supplied client identifier does not establish permission. The server must verify who is making the request and their right to act for that client.

For unresolved permissions, record “unknown,” a decision owner, and the evidence needed. Keep the action unavailable until the policy is decided. Review delegated access, expired invitations, staff reassignment, and account closure explicitly rather than folding them into an unrestricted administrator role.

Fictional worked example: clients A and B

This example is invented for planning; it describes no client project or observed results. U1 is Client A's contributor, U2 is Client A's administrator, and S1 is a staff reviewer assigned only to A. A1 is A's file, A2 its submission, and A3 its membership register. B1 and B2 are B's file and submission. New submissions start as drafts.

On small screens, scroll the table sideways to read all columns.

Extend the worksheet with separate rows for creating, editing, uploading, inviting, exporting, and deleting. If an external accountant needs invoice exports, define the client relationship and invoice fields that access covers. Granting a broad “client user” role would leave those decisions unanswered.

Write observable allowed and denied scenarios

Connect each matrix row to an acceptance scenario. Record the starting state, user, action, expected message, resulting records, and evidence to inspect. Include allowed paths: a system that rejects everything would satisfy denial cases while failing its purpose.

The following are authored acceptance requirements for the fictional example, not reported test results or an OWASP test suite.

On small screens, scroll the table sideways to read all columns.

The attachment check verifies which client owns an existing file. It cannot determine whether a new upload contains another client’s information; agree a review and correction process. Revocation blocks future downloads but cannot retrieve copies already downloaded.

Treat each scenario as an independent check with its stated starting conditions. Restore fictional records between checks so an earlier approval or revocation does not change the next scenario. Keep expected observations separate from recorded results, with the implementation version and evidence reference attached.

Inspect actual records alongside messages. During outage recovery, task count stays zero until delivery succeeds, then becomes one. Test interrupted uploads: no incomplete attachment becomes submittable; inspect saved state before retrying. Test connectivity loss, login failure, and portal unavailability separately. Without a saved receipt, do not claim submission. If its outcome is uncertain, report it as unknown and check authoritative state after reconnecting before retrying. Provide an external support route, name its intake owner, and reconcile manual intake before retrying. For your own scenarios, name who records discrepancies and who decides whether an unresolved failure blocks release.

Name the source of truth and integration owners

A source of truth is the system whose value governs a particular field or state. Define it at that level: the portal might own submission content while a work system owns its task status. A displayed copy needs a freshness rule, a conflict decision, and an owner who can reconcile disagreement.

For fictional integration I1, use this ownership record:

On small screens, scroll the table sideways to read all columns.

Specify alert recipients, the wait before escalation, and recovery evidence in the blank worksheet. Assign ongoing ownership for invitations, permission reviews, support, retention, and history access. Record relevant history fields, including actor, client, action, time, and outcome, without copying sensitive file contents into logs.

Replace owner labels with responsible people when completing your plan. Give support staff a defined client scope and a way to escalate disputed access. A technical owner can repair a connection; operations decides which conflicting business record governs. Before inviting clients, name who provisions accounts, trains staff, accepts the workflow, and receives support ownership. Handoff includes account and supplier access, operating instructions, export and recovery procedures, and a way to accept later changes.

Use the worksheet to decide what to buy or build

Ask an existing portal supplier to demonstrate your matrix and scenarios with representative accounts. Buying fits when its permission model and workflow meet the requirements without awkward exceptions. Custom development gives you control over those rules but requires funding for maintenance, support, and integration changes. A mixed approach can preserve existing record systems while adding a focused client interface.

GOV.UK's technology guidance recommends exploring interfaces and mapping components to build, buy, or obtain freely. That public-service planning method can inform this decision; it establishes no price advantage for either option.

Take the completed worksheet and unresolved owner decisions to a software partner. If considering Wavelength's 100-hour app sprint, use them to assess whether one workflow fits a scoped first build. Book a call to talk through that workflow, its access boundaries, and integration unknowns, and agree a practical next step. Use the worksheet to agree requirements; your engineering partner still needs to design and test access controls.