Build an IT service request form on SharePoint

One form that changes with the request

Start with the request type. When someone picks hardware, the form shows asset and location fields. Pick access instead and it asks which system, and which manager approves. Conditional rules show and hide those sections, so each person sees a short, relevant form rather than every field IT has ever needed.

Make the useful fields mandatory

A ticket that arrives without the basics costs a round trip to chase them. Rules can require the fields that matter for the chosen request type, so a hardware request cannot be submitted without an asset tag and an access request cannot be submitted without the system named. The form does the chasing up front.

Every ticket lands in the list

On submit, the request saves as an item in your SharePoint list, so it joins the queue your team already triages. Your views split it by type or priority, and the history lives with the rest of your SharePoint data.

Routing and approvals

The form captures the request. For what happens next, an assignment or an approval, a Power Automate flow on the list does that work. It triggers on the new item, then routes or notifies. The form does not include a separate approval engine of its own, so lean on the list and a flow for that part rather than expecting the form to run the workflow.

Ask for these on every request

Whatever the type, a handful of fields do the heavy lifting at triage. Collect them once at the top and the specialised questions can stay hidden behind the type.

Ask who the request is for using a people picker rather than typed text. Someone raising a ticket on a colleague's behalf is common, and a real account resolves to a real person you can assign work about instead of a name you have to interpret.

Ask how badly it hurts. Everyone marks their own request urgent, so urgency alone sorts nothing. How many people are affected, and whether there is a workaround, gives you a queue you can actually order.

Ask where they are, from a list of your real sites rather than free text, so hardware jobs can be batched by trip. And let them attach a screenshot: one image saves more back-and-forth on a broken-thing ticket than any amount of description.

Internal form or public one?

Both exist for a reason and the choice is about who raises the tickets. If everyone using the form is a staff member signed in to your tenant, use the internal list form: it inherits their identity, so you know who submitted without asking, and a people picker resolves against your own directory.

If requests also come from people outside the tenant, contractors on site or tenants in a building, then a public form is what you need, because they have no account to sign in with. The trade-off is that you have to ask who they are as a question on the form rather than reading it from their login.

Ship four request types, not forty

The failure mode with IT intake is designing for every request type at once, ending up with a form nobody finishes and a taxonomy nobody agrees on. Ship three or four types that cover most of the volume, watch what people actually pick, and add types when the evidence arrives. If the form is a public one, the completion rate will tell you fairly quickly whether you have asked for too much.