Stop Clients Seeing Each Other’s Uploads

Use an upload-only request or separate authorized client destinations. Test that one client cannot browse another client's files before collecting real documents.

A shared folder that lets people contribute can also let them view material already inside it. Do not infer isolation from the word 'upload' on a button. The required result is specific: Client A can submit the requested file, the internal owner can retrieve it, and Client B cannot see A's submission or identifying details.

This guide concerns incoming collection. It is not an outbound bidder-room setup guide or a claim that any particular provider automatically delivers the correct isolation for your account.

Define who should see each submission

Write down the collection purpose, client groups, internal recipients, and required permissions before choosing a folder. If each client is sending financial statements, identity evidence, or contract material, there is usually no reason for unrelated clients to browse the collection destination.

Separate upload permission from reading, editing, downloading, deleting, and seeing who else participated. A client may need a receipt without needing continuing access to the entire folder. If the workflow requires clients to review their own submissions later, that is an additional requirement to configure and test, not something to assume from an upload-only request.

Give each destination an internal owner. A request with no responsible owner can remain open after the case ends, accumulate unnecessary material, or be forwarded to someone who has no valid reason to submit. Decide how the request is closed and how received files move into the case workflow.

Choose an incoming collection feature deliberately

Microsoft documents a file-request workflow in which request recipients upload without browsing the destination. Microsoft: create a file request Dropbox also provides file requests. Dropbox: create file requests These examples illustrate why an incoming-request feature can differ from sharing an ordinary collaboration folder.

Check your actual account, plan, administrator settings, and current provider documentation. A feature available in one environment may be disabled in another. Do not weaken an organization-wide policy just to make a request button appear; ask the administrator for an approved collection method.

Where an upload-only request is suitable, select a private destination with appropriate internal access. Where identity-bound client access is required, use an approved feature that supports that requirement and test it. A request link that permits uploads is not automatically proof of the uploader's identity, so reconcile submissions with the case record.

If the platform cannot provide the needed separation, use distinct approved client destinations or another collection method. Do not compensate by asking clients not to look at each other's files in a broadly shared folder. A written instruction is not a substitute for the actual access boundary.

Inspect the destination and inherited access

Before distributing the request, review who can access its underlying destination. Internal broad groups, previous guests, shared links, and inherited parent permissions can affect confidentiality even when the client-facing request is upload-only. Ask the administrator to help interpret the effective access where necessary.

Use neutral internal labels that do not expose a client relationship in an external request title. Do not place a list of all clients in a shared instruction file or in the request description. Isolation includes names, filenames, folder structure, and participation details, not only document contents.

Check whether notifications reveal information to a broad mailbox. A useful alert can tell the assigned owner that a submission arrived without distributing the uploaded file to everyone copied on a general thread. Review the actual message your test produces rather than assuming notifications contain only harmless data.

Keep staging separate from approved case materials. An incoming upload should be reconciled and handled through the organization's screening process before it becomes evidence used by another team. Isolation prevents cross-client browsing; it does not establish that the incoming file is complete, authentic, or safe to open.

Run a two-client test with nonsensitive files

Create two authorized test identities or use approved test sessions that represent the real clients. Avoid testing only while signed into the administrator's account, because that account may legitimately see everything. Use dummy records clearly marked as test material.

From Client A's session, submit a file with a recognizable harmless label. Observe the completion screen and any receipt. Try the normal navigation available to that session: does it show existing files, other uploaders, or a parent folder? Do not probe unrelated systems; remain within the authorized feature test.

Repeat from Client B's independent session. Confirm that B cannot see A's dummy submission or identifying details. Then have the internal owner retrieve both submissions and reconcile them to the correct test clients. If uploaders type their names themselves, check how that information is validated rather than treating it as verified identity.

Test an unintended recipient session if your policy requires it. Determine whether anyone holding the link can submit and whether that behavior is acceptable. A workflow can provide reading isolation but still need a separate process to verify who submitted the files. Record both results distinctly.

Check the entire route after upload

Do not end testing at the first successful upload. The most sensitive mistake may occur when an employee moves received files to a broadly shared case folder or forwards the notification with the document attached. Test the real downstream route using the dummy records.

Document failures with the test identity, destination, time, visible behavior, and the setting or workflow that needs correction. Keep screenshots nonsensitive. Retest after a change, because fixing one access path may not remove a separate shared link or inherited permission.

Worked example: collect records from two advisory clients

Imagine a fictional adviser collecting quarterly evidence from two unrelated businesses. The assistant initially plans to send both clients a link to one collaboration folder. Before any real records are uploaded, the owner asks whether either client could browse the other's files.

The team instead chooses an approved incoming-request feature and a private internal destination. They test with two dummy clients. Both can submit, neither can browse the other's file, and the assigned owner receives the items. However, the notification goes to a general office group with a client name in its subject.

The team corrects the notification route and repeats the test. They also decide how each submission will be matched to the case, because upload access alone does not establish identity. After reconciliation and approved screening, documents move into their assigned case locations with the intended internal permissions.

At the collection deadline, the owner closes the request and confirms the behavior through a test session. They retain the received evidence under the existing case policy. The result is an isolated intake workflow with identified ownership, not merely a folder that happens to accept uploads.

A final check for the release owner

Have the owner inspect the dummy filenames as well as the file contents during the test. A client name embedded in a receipt, folder title, or shared activity view can breach the intended separation even if nobody can open the document. If an assistant needs to acknowledge receipt, use a case-specific message to the verified client contact rather than forwarding an intake notification wholesale. Remove test records through the approved process after the result is recorded. Keep the evidence of the test, its limits, and the configuration date so a later administrator can determine whether a new change requires retesting.

Provide clear instructions and handle incorrect submissions

Tell clients what is requested, the purpose, the deadline, permitted file types, and a verified contact for questions. Ask for the minimum necessary material and avoid telling them to upload an entire archive when a specific record will do. Explain whether they can retrieve or replace their own submission after sending.

If a client sends the wrong document, handle the correction privately. Do not post the file into a shared discussion to ask whose it is. Record the case reference, involve the assigned owner, and follow the relevant deletion or retention process for unnecessary material.

If cross-client access is discovered, stop further collection through the affected route and involve the responsible security or privacy contact. Determine what was visible and to whom using available evidence. Removing one link may limit future access, but do not assume it retrieves downloaded copies or resolves every notification already sent.

For recurring collection, periodically retest with harmless files. Account policies, staff changes, folder moves, and notification changes can alter the effective workflow. A previously correct setup needs revalidation after a meaningful change rather than permanent reliance on its first approval.

Frequently asked questions

Is a shared folder the same as an upload-only request?+

No. Evaluate the actual feature and effective permissions. A collaboration folder can grant reading access as well as contribution access.

Does upload-only access verify the client’s identity?+

Not necessarily. Check the feature’s identity model and reconcile each submission through an approved case process.

Can I promise clients their files are isolated without testing?+

No. Test with independent nonsensitive client sessions and inspect downstream storage and notification paths before real collection.

Before you proceed

Isolation is an observable workflow result. Verify the client-facing path, the internal destination, notifications, and the case handoff before requesting sensitive records.

Parent guide

• Request Sensitive Documents From Clients

Related articles

• Request Sensitive Documents From Clients

• Check File Permissions After Moving a Folder

• Check Whether a Document Request Is Genuine

Sources and editorial disclosure

Primary documentation reviewed October 13, 2026. Worked examples are fictional illustrations. Checklists and decision frameworks are editorial recommendations; product-specific facts are linked to official documentation. These guides do not claim that signed-in product tests or customer projects were performed.

• Microsoft: create a file request

• Dropbox: create file requests

VDR Directory is published by the team behind SendNow. This ownership is relevant when evaluating any product mention. Stock photos illustrate general context; they do not demonstrate software features or identify actual affected people. Controls and tool availability depend on the provider, edition, version, device and configuration. No guide guarantees confidentiality, regulatory compliance, acceptance of altered documents, or search rankings.