OneDrive file request: collect client files without sharing your folder

A OneDrive file request gives clients an upload link to a folder you choose. They can send files without a OneDrive account and cannot browse, download, edit, or delete the folder’s contents or see other submissions. That makes it useful when you need a project brief and original images without opening your working folder to the client. Microsoft Support documents these permissions.

The upload confirmation still leaves a job for you: check which project each file belongs to and whether you have the usable, approved version. The downloadable invitation, intake register, and correction replies below help you handle that part.

Check that file requests are available

File requests apply to work or school OneDrive. Microsoft says the feature is unavailable for OneDrive home and its 21Vianet and Germany services. An administrator must enable both Anyone links and file requests; disabling Anyone links also disables requests. If Request files is missing from your folder menu, ask your administrator to check the tenant’s current settings against Microsoft’s file request administration guidance.

That guidance names a OneDrive setting, OneDriveRequestFilesLinkEnabled, separately from the SharePoint setting CoreRequestFilesLinkEnabled. A site setting, RequestFilesLinkEnabled, may also matter. These names can make a support request more precise, but the administrator needs to reconcile the settings and permission requirements for your tenant.

Create the request in a project folder

Create or choose a destination folder dedicated to the project, then select Request files for that folder. Give the request a description a client will recognize, such as “P104 project brief, original images, and approved copy.” Select Next, then either Copy link or enter addresses to send Microsoft’s email message. Select Done to finish. You can later change the description by selecting the folder and Request files again, according to Microsoft Support.

Sending the invitation to named clients does not restrict uploads to those people. Anyone holding the request link can submit, including someone who receives a forwarded copy. If submissions must be limited to authenticated, named people, ask your administrator for an approved method before sending this link.

Use the description to tell clients what belongs in the request. Keep the destination folder’s name useful to your own team, too: it should help you find the intake when you review files. Creating a separate request for a separate project also makes it easier to close one intake without confusing it with another.

Send a message clients can act on

Download the client upload invitation and closing message. Replace every bracketed field before sending, including the actual request link, project reference, contact, and deadline.

A short invitation can carry the essential details:

Project: [PROJECT] ([REFERENCE])
Please upload the brief as PDF or DOCX, original images as JPG or PNG, and approved copy as TXT or DOCX.
Upload link: [REQUEST_LINK]
Please send these by [DEADLINE_AND_TIME_ZONE].
For a question or correction, contact [CONTACT].

Use a deadline that includes a time zone. If a filename needs to identify the job, you can ask the client to include a neutral reference such as P104; treat that as a matching aid, not proof of who sent it. Use your own reference and keep the same one in the request description, message, and filenames.

The recipient follows the link, chooses Select files, can use Add more files, and then selects Upload. Microsoft says the recipient receives a successful-upload notification and the folder owner receives an upload email. Uploaded filenames receive an uploader prefix; a duplicate name receives a number. Do not build your intake instructions around a presumed exact filename pattern. Check the files that arrive.

Separate arrival from acceptance

An upload email tells you something arrived. It does not tell you that the PDF opens, the images belong to this project, or the copy is approved. The blank intake register has columns for the project reference, expected file, arrival state, content check, follow-up, and confirmed channel. Open it in a spreadsheet and fill it in as you review submissions. Its states are your own tracking choices, not OneDrive statuses.

Open the worked intake example alongside the blank register. P104 is an illustrative job; its suggested filenames are the names you ask the client to use before uploading. No OneDrive upload is represented by these rows.

Expected item	Example review	Next action
Brief	A file arrived, but its content was unreadable	Ask for a replacement PDF
Original image	A file arrived for the wrong project	Request the correct original image
Approved copy	The expected file has not arrived	Ask whether the copy is ready or still being drafted
Revised brief	A later P104_brief_v2.pdf opened and matched the reference	Mark that item accepted after reviewing the content

When a client says, “I uploaded it,” first confirm receipt, then check the content against the request. A corrected file is another submission to assess; do not assume the earlier file was replaced or that a duplicate filename identifies the approved version. Record what you accepted and what still needs follow-up.

Handle names and corrections carefully

Microsoft says an anonymous uploader enters a first and last name, but that name is not validated. When an uploader is signed in, their identity is recorded. Neither a typed name nor a project reference in a filename should stand alone as your identity check.

If the sender matters, confirm a questionable submission through the client contact channel you already know. For example, if images marked P104 appear to belong to another job, ask the established client contact which files they intended to send. Keep that confirmation alongside your local intake record rather than guessing from the uploader’s name.

The recipient help replies cover an old link, a page that exposes folder contents, duplicate names, wrong files, and an upload without confirmation. Choose the reply that matches the actual page and folder state. If a client says they need to sign in, first check which link they opened; a normal folder share and a file request serve different purposes.

Check the files before accepting the submission

For a brief, open the document and compare its project reference with the request. Look for the section you actually need to start work. A PDF that opens but contains only a cover sheet is still an incomplete brief. Record the missing section in the follow-up column, so your reply asks for a specific correction.

For an image, inspect the picture itself before treating a matching filename as a match. If the invitation asked for an original JPG or PNG and the client sends a screenshot inside a document, say which source file you need. A filename such as P104_images_01.jpg is a naming convention you propose; it does not establish resolution, rights, or whether the client has supplied the original.

For approved copy, confirm whether the uploaded document is the text to use or a draft still awaiting approval. If the client has no final copy yet, leave the item expected and ask for a delivery date. Marking the upload received and the content accepted as separate decisions prevents a folder full of files from looking like a finished intake.

Keep your request list modest. If you need one brief and two images, name those items in the message rather than asking for “everything.” The register can then show a specific missing image or unreadable brief instead of a vague incomplete-project label.

Resolve common intake problems

The link no longer works

A link may have an administrator-set expiry, and a deleted request link cannot be restored. Check whether you closed the request; if you did not, ask your administrator to check the applicable expiry setting. If the link was deleted, create a new request and send its new link. Do not promise clients a fixed link lifetime.

The client sees folder contents

Pause the intake and check the link you sent. A file request should not let its recipient browse the destination. If you sent an ordinary folder share, review that share’s access with the responsible owner and send a genuine request link. Ask the client to wait while you correct it; changing the wording in your email cannot change a link’s permissions.

The upload succeeded, but the content is wrong

A success notification addresses the upload, not your content check. Tell the client exactly what needs correcting, such as “The images appear to be for another project; please send the original JPG or PNG files for P104.” Leave the item open in your register until you check the correction.

The client uploads a replacement

Ask for a distinct version name, such as P104_brief_v2.pdf, with a message identifying the earlier file it replaces. Keep the original extension; renaming a Word document to .pdf does not convert it. Inspect the new document and mark the earlier one superseded in your own register. OneDrive’s duplicate-name number helps keep names distinct, but does not tell you which version the client approved.

Close the request when intake ends

Once you have checked the needed files and followed up on missing items, close the link you sent. In OneDrive, open the folder’s ellipsis menu, choose Manage Access, find the request under Links Giving Access, open that link’s ellipsis menu, select x, and then Delete link. Microsoft says deletion is irreversible; a later round of submissions needs a new request and a new link. Send the kit’s closing message so the client knows where to raise a remaining correction.

Microsoft’s feature and administration instructions were checked on October 7, 2026. The templates and P104 example are original reader resources. These instructions are based on the documentation; the upload flow was not tested in a Microsoft 365 tenant.