What should a client portal actually do?

Give a portal a task people need to return to: review a current document, supply a missing detail, make a decision or see what happens next. A login screen alone does not make the work easier.

Choose the task before adding the account

Describe the moment someone returns. What changed since their last visit? What can they do now? Who is waiting for the result? If the only task is reading a general service description, an ordinary public page may be enough.

For a real project, list the information that needs restricted access and the people who need it. Check whether an existing client or project tool already meets the need. A second account can introduce another place where information goes out of date.

Write the complete route: invitation, sign-in, task, confirmation and human help when a step fails. For each step, name the person acting, what they need to see and how the next person knows the task is finished. Test the invitation from the recipient's inbox, not from an administrator's already-open account.

Approval is not the same as access

Decide separately who may view, upload, comment, approve and manage access. An assistant may coordinate a project without making its final decision. An administrator may maintain the account without being authorised to approve work on a client's behalf.

OWASP's authorization guidance distinguishes identity from permission, recommends least privilege and says access should be denied by default. These are implementation questions for the builder to verify. A role table in a brief does not itself enforce security.

A forward should not become a wider invitation.

Define what happens if an invitation or document link is forwarded. The recipient should receive only access that was intended for them. Also decide who can add someone, remove them or change a role, and how those decisions are recorded.

A private office reviewing a design selection

Illustrative example: an assistant coordinates a selection for a principal while a design practice prepares revisions. The portal's first task is reviewing the current selection, not reproducing every document from the engagement.

• The assistant sees the agreed project material, gathers questions and identifies what needs the principal's attention.
• The principal can review the named revision and record a decision through the agreed process.
• The practice publishes a revision, answers questions and records the next action.
• The administrator manages access without silently acquiring the principal's approval role.

Record those roles for this project, then test each one with separate fictional accounts. They are an example to adapt, not a default policy for every office. A professional practice must approve its own handling and retention requirements; this worksheet does not provide professional or legal advice.

Name the version and the next action

The marked-up version should still have a name.

Show the document title, revision, date and status together. If a new revision replaces an older one, make the current version identifiable. Link a decision to the exact version reviewed. Do not treat “opened,” “downloaded” or “comments received” as a client's approval.

Use states someone can act on: “Waiting for your review,” “Changes requested” or “Approved by the named reviewer.” Explain what follows and who handles it. If a notification is sent, keep sensitive detail out of the preview unless that disclosure has been deliberately agreed.

Keep questions short, labels visible and errors understandable. W3C's forms guidance covers labels, instructions and feedback. Offer a human contact route when access or a document fails; a generic error must not be the end of the project.

Test the handoff, including when someone leaves

1. Invite a fictional participant. Confirm the intended person can sign in and find the task.
2. Try each role. Confirm people can perform the allowed actions and cannot open another project's material.
3. Forward a test link to an uninvited account. Check the access decision, not just the button's appearance.
4. Upload a revision, record a test decision and confirm exactly what changed and who sees it.
5. Try a failed upload and an unavailable notification service. Confirm the person can understand the state and ask for help.
6. Remove test access. Check the agreed treatment of active sessions, old links and retained records.
7. Export a test project and follow the recovery instructions with its maintenance owner.

Record results against the proposed roles and process before using real client material. Keep the first version small enough to explain. Add a feature when it resolves a demonstrated task, with its access and maintenance decisions included.