The SharePoint list form designer, explained

What it replaces

When you open a list item in SharePoint, you are looking at one of three built-in forms: NewForm for adding an item, EditForm for changing one, and DispForm for reading it back. They are generated from the list columns, so they always work, and they ask nothing of you to set up. The catch is that they show every field to everyone, in one long column, with no way to react to what someone has answered and no real say over how it looks.

A SharePoint list form designer takes over those three forms. Instead of a generated panel you get a canvas, and the form you build there becomes the form your team sees when they add or edit an item. Forms365 Workspace is that designer. It installs inside your own Microsoft 365 tenant as an SPFx solution and renders on top of the real list, so the columns, the data, and the permissions are the ones you already have.

How it works under the hood

The important part is where it runs. Because Workspace deploys as an SPFx solution in your tenant, the form loads in the same SharePoint context the person is already signed in to. Reading and writing the list happens in the browser under that user's own permissions. Nothing hops out to a separate application to store your records, so a submission is an ordinary SharePoint list item sitting in the list it always would have.

That has a practical upside beyond tidiness. Your existing views still show the data, your existing permissions still apply, and if you have a Power Automate flow set to run on that list, it keeps firing on new items the same as before. The form changed. The list did not.

What you can put on a form

The canvas holds far more than the default editor. It falls into a few groups.

Your list columns

All the common SharePoint column types are covered for both reading and writing: text and multi-line text, number and currency, yes/no, date and time, choice and multi-choice, lookup, person or group, and managed metadata, along with hyperlink, image, location, attachments, and file upload. Drag a column onto the canvas and it binds to the real field behind it.

Pickers that resolve properly

A person field uses a people picker that searches your directory and stores a real account rather than a typed name. A lookup field searches the related list and, when the item someone needs is not there yet, quick-add lets them create it inline without leaving the form. A managed metadata field offers your approved terms from the term store, so categories stay consistent. There is a companion guide on adding a working people picker if you want the detail.

Related records with linked lists

Some forms need child rows: an order with line items, a risk with its controls, an audit with its findings. Linked lists let you edit those child rows inside the parent form and write them to a real child list with a proper foreign key on save. They are genuine related items, not a blob of JSON stuffed into a single column, so you can report on them like any other list.

Rich controls and layout

Beyond plain fields there are signatures, ratings, a Likert matrix for surveys, rich text, an image with markup, a QR code, and a document viewer for showing a PDF in context. To arrange all of it you have sections, panels, columns, tabs, and tables, so a long form can read like a real business document instead of a single tall stack of boxes.

Logic, calculations, and quizzes

A form that only collects is doing half the job. Rules let it respond. You can show or hide a field, enable or disable it, make it required, or set its value, all based on what someone has already entered. Calculated values work out a total or a date as the person types, and cross-field validation can block a submission when two answers contradict each other. If the form is a training check or an induction, quiz mode adds correct answers and a pass mark. You set all of this the same visual way, no script involved. There is a fuller walkthrough in the guide on SharePoint form conditional logic.

For the rare form that needs something the designer does not offer, there is an HTML, CSS, and JavaScript editor with a small scripting API. Most teams never open it, and that is the point: the no-code layer covers the everyday work, and the code layer is there only when a genuine edge case turns up.

What happens after someone submits

On save, the form writes each answer to its list column, and any linked child rows to their child list. From there a few things can follow. Workspace can generate a PDF report of the submission, useful for a receipt or a signed record. It can call an on-submit webhook over HTTPS, with optional HMAC signing, so another system hears about the new item. And because the record is a normal list item, a Power Automate flow with a list trigger can pick it up and carry on with approvals or notifications. You connect to tools like Make or Zapier the same way, through the webhook, rather than through a built-in connector.

Building one, step by step

1. 1

   Point the designer at your list

   Connect Forms365 Workspace to the SharePoint list. Its columns appear on the canvas straight away, already bound to the real fields.

2. 2

   Lay out the form

   Drag fields into sections, columns, or tabs. Group the things that belong together, since you will often show or hide them as a group.

3. 3

   Add rules and calculations

   Use the visual builder to set show/hide, required, and set-value rules, plus any totals or validation the form needs.

4. 4

   Preview on every device

   Fill the form the way a real user would in the live preview, and check it on the desktop, tablet, and mobile toggles before anyone else sees it.

5. 5

   Publish to the list

   Publish, and your form becomes the NewForm and EditForm for the list. Every published save is a restore point, so you can roll back if a change goes wrong.

Built a good form once? Save it as a template or a suite and install it to another site or tenant, where it re-wires its linked lists and lookups to the lists there. That is how a form you designed for one team becomes a starting point for the next.

Where it fits, and where it does not

The designer is built for internal SharePoint work: people who are signed in to your Microsoft 365 tenant, filling in a form on a list they have access to. It targets SharePoint Online and Microsoft 365, not on-premises SharePoint Server, and it is built to target WCAG 2.2 AA so the forms are usable for everyone on the team.

What it deliberately does not do is open a form to the outside world. If you need customers, contractors, or applicants with no Microsoft account to submit, that is a public web form job, and it belongs to Forms 365 Web instead. The two products share the same idea, forms that write to SharePoint, split along the line of who is filling them in.

Common questions