Binding to a SharePoint list
How forms find their list, what schema reconciliation does on load, and what happens when columns change.
A SharePoint Forms365 form is always bound to exactly one SharePoint list. Binding happens when you create the form ("From an existing SharePoint list") and is stored as the list's GUID in the form definition, not the display name, so list renames don't break anything.
What gets bound
Three things:
- The list's identity, site URL + list GUID
- The column schema, internal names, types, choice options, lookup targets, required flags
- The item id (for edit/display forms), read from the URL or the SP form customizer context
The form designer reads the schema once when you start authoring; every field's default properties (label, required, options, lookup target) inherit from the SP column setting.
What happens at runtime (schema reconciliation)
On every form load, SharePoint Forms365 re-reads the live schema and applies any changes to the form. Schema reconciliation is what keeps your form in sync when an admin changes a column in SharePoint without re-saving the form.
Three categories of change:
- A new column was added, the form ignores it (it's not on your form).
- A column was renamed, the form continues to work; internal names are the binding key.
- A column's options changed, Choice fields pick up the new options. Lookup target lists pick up new items at autocomplete time.
- A column was removed, the field is skipped with a console warning. Save still works for the remaining fields.
What does NOT reconcile
Author overrides always win:
- Your custom label, description, placeholder
- Your validation rules, patterns, requiredIf
- Your event handlers (onChange, onValidate)
- Your CSS class, styling, layout positioning
So safe SharePoint changes (column rename, choice list update, target list change) flow through automatically. Risky changes (deleting a column) leave the form mostly working with a clear warning.
Multi-list bindings
Each form is bound to one list. To gather data from multiple lists, use:
- Lookup fields, show options from a related list
- LinkedList, embed child items from a related list (parent/child)
- f365.sp in custom JS, read or write to any list in the site collection
Changing the bound list
A published form's list binding is fixed at publish time. To re-bind:
- Save As (top-right menu) to create a copy of the form
- In the copy, change the bound list (Properties panel → General → List)
- Publish the copy against the new list
- Retire the original
This indirection is intentional, silently re-binding a published form would lose data on the original list as it now writes elsewhere.