How to set up a project intake form in SharePoint

Short answer: a project intake form can be a single SharePoint list. Each request is one row. The form people fill in is the list's own new-item form. Add columns for what you need to know, make the key ones required, add a Status choice column and a Decision choice column, and build a view that shows only new requests. You can do all of it without code. The exact menu names may differ from what is written here, because Microsoft changes its screens from time to time.

What you are building

You are building one place where every project request lands. A person opens a form, fills in a few fields and saves. The request shows up as a row in a list. Your team looks at the list, picks a decision, and the row shows the result.

Here is the end result:

One list called "Project Requests".
A form with a short set of fields.
A Status column, so you can see where each request stands.
A Decision column, so the answer is written down.
A view called "New requests" for the items nobody has looked at yet.

This guide covers the intake form only. It does not cover how to track the projects after you approve them. For that, see "SharePoint project tracker examples, with a live demo". It also does not cover approval routing. For that, see "A Power Automate approval workflow in Teams, at a fixed price".

Before you start

You need a SharePoint site where you can create a list, and permission to add lists to it. If you are not sure, ask your Microsoft 365 admin. Pick a site your team already uses. A list on a site that nobody visits will not get used.

Take ten minutes first to write down the fields. This is the step most people skip. A form with 25 fields does not get filled in. One way to start is with six to eight fields. You can add more later.

Step 1. Decide the request fields

Here is a starting set for a project request. Change the names to match how your team talks.

Request title: a short name for the project.
Requested by: who is asking.
What problem does this solve: a few sentences.
Why now: what happens if you wait.
Needed by: the date the requester wants it.
Estimated size: Small, Medium or Large. You can use a choice column for this.
Status: where the request stands.
Decision: the answer.
Decision owner: the person who decides.
Decision reason: a short note on why.

The first six are filled in by the requester. The last four are filled in by your team. Keep that split in mind. It matters in Step 4.

Step 2. Create the list

Microsoft's support page for creating a list gives these steps. You can open the Lists app and select "+New list". Or you can go to your SharePoint site's home page or Site contents page and select "+ New", then "List". Choose the "Blank list" option, which is for starting a list from scratch. Enter a name, such as "Project Requests", and an optional description. You can check "Show in site navigation" if you want a link in the site menu. Then select "Create."

The list opens with no items yet. Next you add columns. Select "+ Add column" and choose a column type.

Step 3. Add the columns

For each field in Step 1, add one column. Microsoft's page on creating a column says to select "+ Add column", choose the column type from the dropdown, enter a title in the Name field of the "Create a column" panel, fill in any other required settings for that type, and select "Save".

Pick the right type for each field. Microsoft's page on column types describes these:

Single line of text: short text on one line, such as a name.
Multiple lines of text: longer text over several lines. Use it for "What problem does this solve" and "Decision reason".
Choice: people pick from options you define. Use it for Estimated size, Status and Decision.
Person or Group: a searchable list of people. Use it for Requested by and Decision owner.
Date and time: a date, or a date with a time. Use it for Needed by.

Microsoft also says to choose the data type before you create the column, because changing the type later can damage the data already in it. So take a moment on each one.

A note on the first column. A new list may already come with a title column. If so, you can use it for "Request title" instead of making a new one. The Title column is required by default, so rename it or turn off Require. The exact menu names may differ.

Step 4. Make the Status and Decision columns

These two columns are what turn a pile of requests into a working process.

Create Status as a Choice column. One way to start is with these options:

New
In review
Needs more info
Decided

Create Decision as a Choice column too. One way to start:

Approved
Declined
Not now

Microsoft's column types page says a Choice column can have a default value that is selected automatically when someone adds a new item. Set the default of Status to "New". Then every request starts as New without the requester doing anything. Leave the default of Decision empty. A blank Decision means no answer yet.

Why two columns and not one? Status says where the request is in the process. Decision says what the answer was. A request can be "Decided" with a decision of "Declined". Keeping them apart makes it easy to count how many you approved and how many are still waiting.

Step 5. Make the key fields required

You do not want a request that says only "Need a new tool". Microsoft's column types page says you can specify that a column is required, and then people cannot add an item without entering the information. Find that option in the settings for each column. The exact menu names may differ, so look for a setting about requiring the column to contain information.

One way to start: require Request title, What problem does this solve, and Needed by. Leave the rest optional. If you require too much, people stop filling the form in, or they type "n/a" to get past it.

Do not make Status, Decision, Decision owner or Decision reason required. The requester cannot fill those in, so they would be stuck.

Step 6. Clean up the form people see

By default, the new-item form shows every column. That means a requester sees the Decision and Status fields, which is confusing. You have two ways to deal with it.

Option one: leave the form as it is, and tell people to ignore the team fields. This is the simplest. It works for a small team that trusts each other.

Option two: customize the form. Microsoft Learn describes how to customize a SharePoint list form with Power Apps. From the command bar of the list, you select "Integrate", then "Power Apps", then "Customize forms". The Power Apps studio opens with your form. In that tutorial, Microsoft shows how to make a field view-only by setting its display mode, and how to hide a field based on a condition. When you finish, you save, and then select "Publish to SharePoint". Microsoft says the version that appears in SharePoint is the most recently published version.

Be honest about the cost. Customizing with Power Apps takes more time to learn. It is also one more thing to maintain. If you change a column later, you may need to open the form and update it. Many small teams do fine with option one.

Step 7. Build a view for new requests

A view is a saved way of looking at the list. Microsoft's page on views says you can save a sort and a filter as a view. In the modern experience, one way to do it is:

In the command bar, open the "View options" menu.
Select "Create new view".
In the dialog, enter a name, such as "New requests".
Under "Show as", pick List, Calendar or Gallery. Pick List.
Select "Create".
Set a filter so only items with Status equal to "New" show. Set a sort so the oldest show first.
Select Save view.

Microsoft's page also describes a second way: set the sort and filter first, then save the view under a new name. Either one works. The exact menu names may differ on your screen. Some sites use the classic experience, where you select "Create View" on the List tab, choose a view type, name it, and set the Filter and Sort sections.

Open this view each morning. If it is empty, you are caught up. If it is not, those are the requests that need a look.

Step 8. Add a sample row

Add one test request before you share the list. Select "+ Add new item", or "Edit in grid view" to type into rows and columns. Fill it in like a real person would. Here is an example:

Request title: Faster way to track vendor contracts
Requested by: (your own name)
What problem does this solve: Contract end dates are in three spreadsheets and we miss renewals.
Why now: Two renewals were missed this year.
Needed by: a date about two months out
Estimated size: Medium
Status: New (set by the default)

Check these things:

Does the item appear in the "New requests" view?
Did Status fill in on its own?
Did the required fields stop you when you left one empty?

Then change Status to "In review", and see that the item leaves the "New requests" view. Delete the test row when you are done.

Step 9. Decide who can see what

Think about who should see each request. By default, anyone who has access to the list can see every item. For some teams that is fine. For others, requesters should see only their own requests.

Here is what Microsoft pages say and do not say. Microsoft's support page on list permissions explains that you reach the Permissions page through Settings (the gear icon), then "List settings", then "Permissions for this list", and that you select "Stop Inheriting Permissions" to give a list its own permissions. The same page says you cannot break inheritance on a list with more than 100,000 items. It also says that breaking inheritance and setting item-level permissions is a supported scenario.

To let requesters see only their own requests: open Settings, then List settings, then Advanced settings. Under Item-level Permissions, set Read access to Read items that were created by the user, and Create and Edit access to Create items and edit items that were created by the user. Select OK. This does not limit people with Edit or higher, and team site Members have Edit by default. Give requesters Contribute, and test with their account.

Test it before you trust it. Use an account that is not an owner of the site. Add a request, then check what that person sees. Site owners can still see everything, which is what you want, because your team needs to read all the requests.

If you cannot confirm the setting works for your site, do not promise requesters privacy. Say that requests are visible to the team.

What to avoid

Too many fields. Every extra field lowers the number of people who finish the form. Start with six to eight.
Everything required. People type junk to get past the form.
One column for both Status and Decision. You lose the ability to count approvals.
Free-text status. If people type "ok", "okay", "done?" you cannot filter. Use a Choice column.
Changing a column type after people have used the list. Microsoft warns that this can damage existing data. Plan the types first.
Letting requests arrive in two places. If some people still email requests, the list will be missing items. Pick the list as the one place, and tell people.
Trusting the privacy setting without a test. Check it with a non-owner account.
Nobody owns the "New requests" view. Pick one person who opens it each day, and one backup.
Building the follow-up before the form works. Get the form in use for two weeks. Then add alerts, approvals or reports.

Honest limits

A list form is plain. It does not branch ("if the answer is yes, ask this next") unless you customize it with Power Apps. It does not send a message to the requester when you decide, unless you add a flow. It also depends on people using it. A form that nobody is told about will not collect requests. Tell your team where the form is, pin the link in your team chat, and use it yourself.

Some of the settings here may look different on your site. Menu names and screens change. If a step does not match, search Microsoft's support pages for the name of the task, such as "create a column in a list".

When to get help

You can build all of this yourself in Microsoft 365. If you would rather have it built and tested for your team, I do that. A tracker like this is a fixed price: $5,000 for one, built in 2 weeks. See "What a SharePoint tracker costs". Bring one example of the problem to a free call.

Tell me what's still manual

I am Al Davies. I run 250 High Street LLC and build SharePoint trackers and Power Automate flows for operations teams. I work remotely. The first call is free, and I will not try to sell you anything.

See trackers I built: Tools I built

FAQ

Do I need Power Apps to make an intake form?

No. The new-item form of a SharePoint list works as an intake form as it is. Power Apps is one way to change how the form looks, such as hiding fields or making a field view-only. Start without it.

Can requesters see each other's requests?

By default, anyone with access to the list can see all items. Microsoft says item-level permissions are a supported scenario, but test any setup with a non-owner account before you rely on it. See Step 9 for the setting.

What is the difference between Status and Decision?

Status says where the request is in your process, such as New or In review. Decision says the answer, such as Approved or Declined. Two columns let you count each one on its own.

How many fields should the form have?

One way to start is six to eight. If people leave fields blank or type filler, remove fields or make fewer of them required.

Can I make a column required?

Yes. Microsoft says you can specify that a column is required, so people cannot add an item without entering the information. Look in the column's settings. The exact menu names may differ.