CLIENT PORTAL REQUIREMENTS WORKSHEET
Version: 1.0
Date: 2026-10-04
Author: Wavelength Computer Company
Intended public resource path: /resources/client-portal-requirements.txt

This planning worksheet includes a fictional example. Its expected
observations are proposed requirements, not recorded test results.
Completing it does not establish security or compliance.

HOW TO USE

Start with one workflow. Complete access, integration and testing details
with your software partner; mark missing decisions unknown.

1. Copy the blank sections for one client workflow. Start with what the client
   needs to finish and what the staff member does next.
2. Give users, records, permissions, scenarios, and integrations simple IDs.
   Identify the client owner of each record and the authoritative system for
   each important field or state.
3. Write one permission row for each role, client relationship, record, and
   action. Include active membership, staff assignment, and record-state
   conditions. Include allowed and denied decisions.
4. Link each row to observable scenarios. Check the message AND the actual
   record state, file access, history, and downstream effects. Include changed
   membership, a wrong-client record, repeat submission, and an outage.
5. Assign operations and technical owners for every integration. Decide who
   checks failed transfers, authorizes manual fallback, and reconciles records.
6. Write unknown / owner / next step / decision deadline for missing details.
   Do not fill gaps with guessed permissions. Keep undecided actions unavailable
   until their policy is decided. Record which other decisions they block.
7. Use the same requirements to evaluate a supplier or a custom build. Keep
   expected observations separate from observed evidence. Review discrepancies
   with the person responsible for accepting the workflow.

Do not put passwords, credentials, private documents, or personal identifiers
in this worksheet. Use references to approved records and credential storage.
Replace owner roles with named responsible people when using the blank forms.

BLANK WORKING RECORDS

1. WORKFLOW AND SCOPE

Worksheet owner:
Last revised:
Workflow ID:
Client job and reason:
Staff job and reason:
Starting information / trigger:
Current process:
Finished record / observable outcome:
Client organization or individual:
Can one person belong to several client organizations?:
Decision maker for access policy:
Decision maker for workflow acceptance:
Included actions:
Excluded actions / existing systems retained:
Constraints / evidence source:

Step | Actor | Input record | Action | Resulting state | Next owner
____ | _____ | ____________ | ______ | _______________ | __________
____ | _____ | ____________ | ______ | _______________ | __________
____ | _____ | ____________ | ______ | _______________ | __________

Record-state decisions:
State name:
Who may enter it and from which previous state?:
Who may correct, reject, or reopen the record?:
What happens to already completed downstream work after correction?:

2. USERS, CLIENT RELATIONSHIPS, AND ADMINISTRATION

User reference | Role | Client | Membership/assignment | Granted by | Expiry
______________ | ____ | ______ | _____________________ | __________ | ______
______________ | ____ | ______ | _____________________ | __________ | ______
______________ | ____ | ______ | _____________________ | __________ | ______

Invitation approver:
How an invited identity is verified and linked to its client:
Allowed invitation roles / scope:
Expired invitation behavior:
Delegated access boundaries:
Staff assignment / reassignment approver:
Revocation owner and trigger:
Revocation effective point:
Open-session and saved-file-link behavior after revocation:
Delayed/background work behavior after revocation:
Account-closure owner:
Treatment of retained records and previously downloaded copies:
Permission-review owner / review trigger:

3. RECORDS AND SOURCE OF TRUTH

Complete one copy per record type and separate fields with different owners.
Source of truth means the system whose value governs the named field or state.

Record ID / type:
Client owner:
Sensitive fields / classification owner:
Field or state:
Authoritative system:
Permitted reader / editor:
Portal reads, writes, or displays a copy?:
Copy freshness rule / timestamp shown:
Conflict rule / reconciliation owner:
File storage and delivery access boundary:
Retention period or unresolved decision:
Retention/deletion decision owner:
Export fields / eligible role and client relationship:
Correction / deletion process and owner:
Evidence supporting these decisions:

Record | Field/state | Authoritative system | Portal direction | Owner
______ | ___________ | ____________________ | ________________ | _____
______ | ___________ | ____________________ | ________________ | _____
______ | ___________ | ____________________ | ________________ | _____

4. PERMISSION MATRIX

One action per row. Role alone does not establish access to a client's records.
Write allow or deny and every condition. Unknown policy decisions belong in
section 8; the action stays unavailable until decided. Add rows for viewing,
creating, editing, uploading, downloading, submitting, approving, inviting,
revoking, exporting, and deleting as relevant to the workflow.

Rule | Role/user | Client relationship | Record | Action | Decision/condition
____ | _________ | ___________________ | ______ | ______ | __________________
____ | _________ | ___________________ | ______ | ______ | __________________
____ | _________ | ___________________ | ______ | ______ | __________________
____ | _________ | ___________________ | ______ | ______ | __________________
____ | _________ | ___________________ | ______ | ______ | __________________
____ | _________ | ___________________ | ______ | ______ | __________________

For each allowed row:
Why the job needs this permission:
Policy decision owner:
Linked allowed scenario:
Linked denied/boundary scenario:

For each client boundary:
How identity and current client membership or service authorization are verified:
Which file, export, background, and integration paths need the same boundary:

5. OBSERVABLE ACCEPTANCE SCENARIOS

Copy this form for each allowed path and its denied or failure counterpart.
Include actual state and data observations; a success or error message alone
does not establish the result. Use authorized representative accounts and
appropriate test records when the implementation is ready for evaluation.

External support route available without login:
Intake owner / manual intake reconciliation process:
Uncertain submission: report unknown, inspect authoritative state before retry.

Scenario ID:
Linked permission rule / integration ID:
User role and client relationship:
Starting records and states:
Action / input / delivery path:
Expected access decision:
Expected user-visible message or receipt:
Expected record changes:
Expected records that must remain unchanged:
File content/metadata that must remain undisclosed:
Expected downstream effects / duplicate behavior:
Expected history evidence:
Evidence to inspect:
Reviewer / decision owner:
Observed result: NOT RUN
Evidence reference / implementation version / date:
Discrepancy / next owner / next step:
Does an unresolved discrepancy block release? Decision and responsible owner:

Scenario inventory:
Allowed same-client read/download:
Denied different-client read/download:
Allowed submission:
Denied approval by contributor:
Allowed approval by assigned reviewer:
Denied approval by unassigned reviewer:
Revoked user, open session, and saved file link:
Expired invitation / staff reassignment:
Known wrong-client attachment:
Newly uploaded wrong-client content review/correction:
Repeated submission after lost response:
Integration outage and recovery:
Repeated submission during recovery:
Account closure / export / deletion where included:

6. INTEGRATION OWNERSHIP WORKSHEET

Complete one record per connection, including identity and file services where
they affect the workflow. Name a person for each owner role in a real plan.

Integration ID / connected systems:
Business purpose:
Data fields and direction:
Client identifier and record matching rule:
Authoritative system for each field/state:
Service identity / authorized client and action scope:
Credential-storage reference (no secret values):
Credential renewal owner:
Submission/transfer reference used to identify repeats:
Trigger / expected acknowledgment:
User-visible state while waiting:
When to mark delivery complete and evidence required:
Unavailable dependency behavior:
Retry timing / stop condition / technical decision owner:
How duplicate requests and lost responses are reconciled:
How delayed work handles changed membership or permissions:
Alert recipient / trigger / escalation wait:
Operations owner:
Technical owner:
Manual fallback / authorized operator:
Check for existing downstream work before manual fallback:
Recovery checks / reconciliation owner:
Linked allowed and outage scenarios:
Unresolved decisions / owner / next step:

7. ONGOING OPERATIONS AND HISTORY

Support intake owner:
Who can inspect support records, for which clients?:
Wrong-client file review / correction owner:
What users see while a correction is unresolved:
Permission review owner and review trigger:
Pending-transfer review owner and review trigger:
Retention and deletion owner:
History fields: actor, client, action, time, outcome; additional fields:
Sensitive content to exclude from history:
Who can read history and within which client scope?:
History retention decision / owner:
Recovery owner / required evidence:
Acceptable escalation wait / decision owner:
Who accepts changes after supplier or integration updates?:

8. MISSING INFORMATION AND DECISIONS

Unknown | Evidence needed | Owner | Next step | Deadline | Blocks
_______ | _______________ | _____ | _________ | ________ | ______
_______ | _______________ | _____ | _________ | ________ | ______
_______ | _______________ | _____ | _________ | ________ | ______
_______ | _______________ | _____ | _________ | ________ | ______

Launch handoff: provisioning / staff training / acceptance owner:
Account and supplier access / operations / export and recovery instructions:
Support transfer date and owner / subsequent change acceptance process:

9. BUY, BUILD, OR COMBINE

Existing supplier/product under consideration:
Demonstrated requirements / evidence:
Unsupported requirements / evidence still needed:
Permission and workflow exceptions required:
Record systems to retain:
Custom components proposed:
Maintenance and support owner:
Integration-change responsibility:
Export / exit requirements and evidence:
Budget and ongoing operational commitments to investigate:
Tradeoff accepted / decision owner:
Smallest first workflow to assess with a software partner:
Open decisions required before estimating or implementing that workflow:

FICTIONAL WORKED EXAMPLE

Everything in this section is invented for planning. It describes no client
project, implementation, test execution, or observed result. Required
observations below are proposed acceptance requirements. All tests: NOT RUN.

Workflow: A client supplies a document, submits it for review, and checks its
status. An assigned staff reviewer accepts it or requests a correction.
Initial scope: document submission and review. Billing and electronic signatures
stay in existing systems for this example's first release.

USERS AND RECORDS

U1: Client A contributor; active membership until the revocation scenario.
U2: Client A administrator; active A membership.
S1: Staff reviewer assigned only to A.
A1: Client A file.
A2: Client A submission; new submissions start as drafts.
A3: Client A membership register, including U1 and U2.
B1: Client B file.
B2: Client B submission.

Record/field ownership for this example:
A1 and B1 client ownership and file references: portal authoritative.
A2 and B2 content, submission receipt, and review state: portal authoritative.
A3 membership and role decisions: portal authoritative.
Work-system task delivery acknowledgment: work system authoritative.
Retention details: unknown; product owner to decide before retention design.

PERMISSION MATRIX

Fictional permission rule | Role and user | Client relationship | Record | Action | Decision and condition
P1 | Contributor U1 | Active member of A | File A1 | Download | Allow
P2 | Contributor U1 | No membership in B | File B1 | Download | Deny
P3 | Contributor U1 | Active member of A | Submission A2 | Submit | Allow while draft
P4 | Contributor U1 | Active member of A | Submission A2 | Approve | Deny
P5 | Reviewer S1 | Assigned to A | Submission A2 | Approve | Allow while submitted
P6 | Reviewer S1 | Not assigned to B | Submission B2 | Approve | Deny
P7 | Administrator U2 | Active member of A | Membership register A3 | Revoke U1 | Allow
P8 | Contributor U1 | Revoked from A | File A1 | Download | Deny
P9 | Contributor U1 | Active member of A | Draft A2 | Attach A-owned file | Allow; wrong-client denied
P10 | Contributor U1 | Active member of A | Submitted A2 | Retrieve original receipt | Allow identical reference/payload; no new submission
P11 | Contributor U1 | Active member of A | Draft A2 | Upload new file | Allow; assign A ownership; incomplete upload cannot be submitted

Extend with separate rows for creating, editing, uploading, inviting, exporting,
and deleting before including those actions in scope. Unlisted actions are
denied by default. Proposed policy owner: product owner.

OBSERVABLE SCENARIOS

Run each scenario with its stated starting conditions. Restore the fixtures
between scenarios so a previous approval or revocation does not change a later
scenario's intended starting state. Do not treat the following as test results.

Fictional acceptance scenario | Action and starting state | Required observation
T1 | U1 downloads A1 with active A membership | Correct file delivered; B1 absent
T2 | U1 requests B1 through a saved link | No file content or metadata disclosed
T3 | U1 submits draft A2 with A1 attached | One submission receipt; status submitted
T4 | U1 tries to approve submitted A2 | Denial; approval state unchanged
T5 | S1 approves submitted A2, then requests approval of B2 | A2 approved; B2 unchanged and denied
T6 | U2 revokes U1 in A3; U1 reuses an open session and saved A1 link | Revocation recorded; subsequent download denied
T7 | U1 attaches A1 to draft A2, then attempts B1 | One A1 reference saved; B1 rejected; no further change; B1 undisclosed
T8 | A2 submitted, original receipt stored, one downstream task acknowledged; U1 repeats identical reference and payload | Original receipt returned; submission/task counts remain one
T9 | Work-system integration is unavailable when A2 is submitted | Receipt saved; transfer pending; no delivery claim; recovery produces one task

T10 | Active U1, A2 draft, no complete attachment; start an authorized upload then interrupt it | No incomplete attachment submittable; after reconnect inspect state and confirm one complete A-owned attachment

Portal/connectivity/login failures: without saved receipt do not claim submission.
External support route / intake owner: to assign. Reconcile manual intake before
retrying. During T9 recovery task count stays zero until confirmed, then one.
Handoff: account provisioning, staff training, acceptance owner, support transfer,
account/supplier access, operation, export/recovery, change acceptance process.

Coverage links:
P1 -> T1; P2 -> T2; P3 -> T3; P4 -> T4; P5 and P6 -> T5;
P7 and P8 -> T6. T7 extends the client boundary to attachment references.
P9 -> T7; P10 -> T8; P11 -> T10. T9 checks integration I1 and recovery.

T7 tests a known record's client ownership. It cannot prove that newly uploaded
bytes contain the right client's information. A separate review and correction
policy is required. Proposed owner: operations lead; policy still unknown.
T6 governs future access, including file delivery paths. Revocation cannot
retrieve a copy already downloaded.
Repeat T8 after a lost response. For T9 recovery start with A2 submitted,
original receipt stored, transfer pending and zero downstream tasks. Repeat
the identical reference/payload: return original receipt, keep one submission
and zero tasks while unavailable; after recovery verify one acknowledged task.
Inspect actual records alongside messages. Proposed evidence recorder: engineer. Proposed discrepancy
and release decision owner: product owner.

INTEGRATION I1

Worksheet field | Fictional I1 requirement
Data and direction | A2 submission reference; portal to work system
Authoritative states | Portal owns submission and receipt; work system owns task delivery acknowledgment
Authorization | Service authorized for A; receiving task retains A ownership
Failure and retry | Keep transfer pending; retry the same submission reference; reconcile before manual resend
Operations owner | Operations lead checks pending transfers and reconciles receipts
Technical owner | Engineer maintains connection, credentials, and retry behavior
Fallback | Operations lead checks for an existing task before creating one manually

An A2 submission initiates I1. While the connection is unavailable, the portal
keeps its submission receipt and shows transfer pending. It must not claim that
the work-system task was delivered. Acknowledgment or reconciliation is needed
to establish that task delivery occurred. Repeats must refer to the same
submission, including after a lost response or manual fallback.

EXAMPLE UNRESOLVED DECISIONS

Unknown | Evidence needed | Owner | Next step | Deadline | Blocks
Alert recipient and escalation wait | Support availability | Operations lead | Propose routing and wait | Before outage behavior is accepted | Outage escalation
Retry timing and stop condition | Connection limits and recovery behavior | Engineer | Inspect integration behavior | Before retry design is accepted | Retry implementation
Retention details | Business record requirements | Product owner | Decide record-specific retention | Before retention design is accepted | Deletion design
New-upload correction policy | Intake and review workflow | Operations lead | Define hold and correction steps | Before upload workflow is accepted | Upload acceptance

SOURCE BASIS AND LIMITS

The matrix, blank forms, and fictional scenarios are Wavelength's editorial
analysis. They are not an OWASP checklist or a report of testing.

OWASP Authorization Cheat Sheet: least privilege, denial by default, and
permission validation on every request.
https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html

OWASP Multi-Tenant Security Cheat Sheet, tenant identification and context:
client-supplied tenant identifiers are selectors; authorization depends on
server-verified identity and current membership or service authorization.
https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html#1-tenant-identification--context-management

GOV.UK Choosing technology: explore interfaces and map components to build,
buy, or obtain freely. Public-service guidance informs a planning method; it
does not establish a price advantage for buying or building.
https://www.gov.uk/service-manual/technology/choosing-technology-an-introduction

Architecture-specific testing and access design remain separate work.

NEXT STEP

Bring one completed workflow, its permission boundaries, integration ownership,
and unresolved decisions to a software partner to assess scope. If considering
Wavelength's 100-hour app engagement, assess whether that workflow fits a scoped
first build; this worksheet promises no delivery duration or outcome.
https://wavelength.computer/services/100-hour-apps
https://wavelength.computer/contact