Define the small scenario precisely
The worked decision record uses a synthetic scenario:
- 20 clients;
- two PDF documents per client per quarter;
- clients may view or download only their own files;
- staff upload the outgoing documents;
- inbound upload is optional; and
- no regulated or contractual classification is assumed.
Those assumptions narrow the decision. If the files contain regulated records, high-consequence financial information, identity documents, or material whose disclosure requires formal handling, stop and obtain the appropriate security, legal, and data-owner review. This article does not supply it.
Test configured alternatives before custom code
Microsoft currently documents specific-person sharing, view/edit choices, and access management for OneDrive and SharePoint. It also documents an upload-only file-request feature when an administrator enables it. Those are product-documentation facts, not a recommendation or proof about a buyer's tenant.
Run this existing-service test:
| Required job | Test first | Evidence to retain |
|---|---|---|
| Send a file to one client | Invite a specific synthetic person with view-only access | Sender, recipient, item, effective permission, time |
| Deny another client | Open the direct file URL using a second synthetic identity | Bounded denial with no file content |
| Remove access | Use Manage Access to revoke the first identity | Denial after revocation |
| Review exposure | Enumerate people, groups, and links with access | Owner-approved access list |
| Receive a file | If needed and enabled, test an upload-only file request | Uploader can submit but cannot list or download folder contents |
Microsoft notes that available sharing choices can be restricted by administrators. The buyer must check its plan, tenant configuration, data location, retention, support path, and effective behavior. A documentation page does not complete the test.
Apply five hard stops
1. Identity and recovery
Name the identity provider and test join, sign-in, recovery, and departure. Stop if clients share accounts, recovery depends on the original builder, or a departed client retains access.
Authentication only identifies a user. It does not decide which client's files that user may access.
2. Per-client authorization
Store an authoritative client scope for each file and enforce it at the server or storage boundary. Test direct file identifiers and download URLs using two synthetic clients.
The OWASP authorization guidance supports deny-by-default and per-request validation. A folder name, hidden button, unlisted URL, or difficult identifier is not the boundary.
Stop if the team cannot demonstrate both an allowed and a denied direct-file request without exposing the protected content.
3. File handling
Define allowed formats, size limits, storage location, names, download headers, malware-handling decision, and deletion behavior. If clients upload files, treat them as untrusted input.
The OWASP file-upload guidance is a set of design considerations, not a certification. Stop if the team cannot state where a file goes, who can read it, and how unsafe content is contained.
4. Operation and recovery
Name owners for releases, monitoring, incidents, backup/recovery, user support, and provider administration. Test the critical workflow outside the builder's session and run a recovery exercise on disposable data.
Stop if the original builder is the only person who can identify the live version, change access, find logs, or restore service.
5. Lifecycle and exit
Define access-review frequency, retention and deletion, complete client export, provider exit, and business-owner acceptance. Low volume can make manual review reasonable; it does not make the review optional.
Stop if no owner can revoke a client or produce that client's complete file set without searching unrelated folders and accounts.
Choose the smallest responsible outcome
For the worked scenario, the decision is: configure and test an existing document service; do not build a full portal yet.
If the missing requirement is a status page, reminder, intake form, or staff queue, consider a narrow workflow layer that stores document references while the established service retains files and file authorization. This avoids rebuilding identity, storage, sharing, and access administration solely to add workflow visibility.
Reopen custom development only when:
- a distinct requirement cannot be configured acceptably;
- its value justifies ongoing operation;
- all five hard stops have owners and evidence; and
- the narrow-layer option has been rejected for a recorded reason.
Document count should affect capacity estimates, not the trust decision.
Decision record
- Existing service and plan checked:
- Synthetic identities used:
- Allowed and denied file tests:
- Access review and revocation result:
- Inbound-upload requirement and result:
- Distinct unmet workflow requirement:
- Identity owner:
- Authorization owner:
- File-handling owner:
- Operating and recovery owner:
- Lifecycle and exit owner:
- Decision: configure / build narrowly / investigate / do not build
- Reviewer and review date:
Frequently asked questions
Is a password-protected link enough?
Not by itself. Determine who can forward it, how access is attributed and revoked, what the selected plan supports, and whether the result meets the workflow's actual data requirements.
Does low file volume make a custom portal easy?
It can reduce scale and interface complexity. Identity, authorization, recovery, support, and file-handling consequences remain.
When is a narrow workflow layer appropriate?
When the established document service handles files and access acceptably but the business still needs a small status, reminder, intake, or coordination workflow. Keep the system-of-record boundary explicit.