Five ways to get an anonymous submission into SharePoint

Why the built-in form is out

A form generated from a SharePoint list lives behind the site that holds the list. Opening it means authenticating against your tenant and holding permission to the list itself. For staff that is exactly right. For a customer, a contractor, or someone applying for a job, it is a wall, and no amount of sharing configuration takes it down.

This is worth being clear about because a lot of advice online sends people around the houses looking for a setting that does not exist. The permission model is doing what it was designed to do.

Microsoft Forms with a flow

The most common workaround. Build the questionnaire in Microsoft Forms, set it to accept responses from anyone, then use Power Automate to copy each response into a SharePoint list.

For a short survey this is genuinely fine, and if you already have it running there is no urgency to replace it. What people underestimate is the upkeep. Responses live in Microsoft Forms first and arrive in your list second, which means two places to look when something goes missing. The flow carries a field mapping that nobody documents, and adding a question to the form does not add it to the list. Rich field types are where it strains hardest: lookups, people, and anything with a calculation behind it all have to be reconstructed in the flow.

Request files

SharePoint and OneDrive can ask an outsider to upload documents without signing in. If all you need is the document, this is the shortest path in the list and you should use it.

It collects files and nothing else. There are no questions around the upload, so the context you actually wanted (which site, which job number, who to notify) has to be chased separately or read off the filename.

Guest access

You can invite an external person into your tenant as a guest and give them access to the list. Everything then behaves natively, because they are a real identity in your directory.

The catch is circular. You started out wanting to avoid a sign-in, and this route ends with the person creating or accepting an account before they can type anything. It is a reasonable answer for a supplier you deal with every week. It is a poor one for a public intake form, where most people will abandon at the invitation email.

A public web form

The remaining option is to publish the form itself to a public URL and have it write into the list directly. No Microsoft account, no flow in between, and the submission arrives as an ordinary SharePoint list item in your own tenant. You point the form at a list you already have, or let it create one when you publish.

This is what Forms365 Web does, at route /f/:slug. Where the recipient is a named person rather than the general public, there are single-use invitation links (/f/:slug/i/:token) that tie one submission to one invite without asking anyone to sign in. Being straight about the trade: this is a different builder to the SharePoint-native designer in Forms365 Workspace, so a public form is not the same artefact as your internal list form.

Picking one

Three questions usually settle it. Do you need structured fields, or just the file? If just the file, use Request files and stop there. Is the submitter a named person you already have a relationship with, or the general public? A guest account is tolerable for the first and fatal for the second. And how much does the data matter once it lands? The more your team relies on views, permissions, and flows on that list, the less appealing it is to have responses staged in a separate product first.