Where your form data lives
The end to end path your data takes, from a filled in field to a SharePoint list item, and every place Forms 365 touches it along the way.
Your SharePoint list is the system of record. SharePoint Forms365 replaces the form, not the storage. Every submission becomes an ordinary item in a list you already own, in your own Microsoft 365 tenant, and it stays readable by every tool that can read a SharePoint list.
If you only read one line: on the default configuration, a submission goes straight from the user's browser to your list. It does not pass through a Forms 365 server on the way.
The end to end path
- Design. An author builds the form in the designer and binds it to a specific SharePoint list. The list and its columns already exist, or you create them first; Forms365 reads that schema rather than inventing its own.
- Publish. The form definition is uploaded as an HTML file into that site's Site Assets library, and the list's New, Edit, and Display forms are associated with the Form Customizer extension.
- Fill. A user opens the list and clicks New, or opens a page carrying the Form Host web part. The runtime reads the definition from Site Assets and renders the form.
- Submit. The browser writes a list item directly to your list, using the signed in user's own SharePoint permissions.
- Manage. From this point the record is a normal list item. Nothing about it is proprietary.
How users submit and manage the data
- Submitting happens in SharePoint, either on the list form or on a page. The user needs no Forms365 account and no licence of any kind. They only need permission to add an item to the list.
- Permissions are the submitter's own. The write runs as the signed in user, so SharePoint's own access rules decide the outcome. If a user cannot add to the list, the save fails. Forms365 never grants access to data a user could not otherwise reach.
- Editing uses the same form. Opening an existing item shows your Edit layout, and the read only view shows your Display layout, both replacing SharePoint's defaults.
- Validation, required rules, and conditional logic run before the write, so the item that lands in the list has already passed the form's rules.
Where each piece is stored
| What | Stored in | Notes |
|---|---|---|
| Submitted field values | Your SharePoint list, one item per submission | Normal columns, normal values |
| File attachments | The list item's attachments | Standard SharePoint item attachments |
| Signature panel images | An Image column on the list item | Written after the item is created |
| Images uploaded on a form | Your Site Assets library, or inline on the item | Depends on the field's setting |
| Repeating rows (linked list) | A second SharePoint list you nominate | Child items, linked to the parent item |
| The published form definition | Your site's Site Assets library, as HTML | Design only, no submitted values |
| Form designs and version history | The Forms365 workspace database | Design only. Submissions are not copied here |
| Reusable signature library (opt in) | The Forms365 workspace database | The saved signature image, for members who choose to save one |
Viewing, editing, and reporting
Because the data is ordinary SharePoint list data, everything SharePoint and Microsoft 365 already do keeps working, with no connector and no export step:
- List views, filters, sorting, grouping, and column formatting
- Search, including tenant wide search over the item's columns
- Export to Excel, or Open in Power BI straight from the list
- Power Automate flows triggered on item created or modified
- Version history and the recycle bin, per item, as SharePoint provides them
- Permissions and retention governed by your existing SharePoint policies
Forms365 adds two reporting conveniences on top of that:
- A report builder that renders a submission to PDF and can attach it to the item, drop it in a document library, or email it.
- On submit webhooks, which notify a system you nominate when an item is saved.
When Forms 365 servers are involved
Three features are opt in, and each is worth knowing about because data leaves your tenant when you turn one on:
| Feature | What is sent | What is kept |
|---|---|---|
| AI form generation | The list's column schema and the author's prompt | Nothing about submissions. This runs at design time, never at fill time |
| Report PDF rendering | The field values needed to fill the report template | Rendered in memory and returned. A report attached to a webhook is stashed behind an unguessable link until its short expiry, then deleted |
| On submit webhooks | The submission payload you configured, relayed to your endpoint | Only the temporary report file above, when a report is attached |
Leave all three off and no submitted value ever reaches a Forms365 server.
What happens if you remove Forms 365
Your data is unaffected, which is the point of storing it in SharePoint:
- The list and every item remain exactly as they are.
- The New, Edit, and Display forms revert to SharePoint's default forms.
- Attachments, image columns, and child list items stay where they were written.
There is no migration to run and no proprietary format to unpack, because there was never a second copy of your data to begin with.
Where to go next
- Binding to a list, how the schema maps to fields
- Permissions, who can see and who can submit
- Publishing, what publish actually writes