Draft Auto-Save

When a user starts filling in a new form and then cancels or closes the panel without saving, DFFS automatically keeps a draft in the browser. The next time the same user opens a new form for the same list, they’re offered the chance to pick up where they left off.

1. What it does

• On cancel/close of an unsaved new form, the entered values are saved as a draft in the browser’s local storage.
• The draft is scoped to the site + list + user, so it only reappears for the same person opening a new form on the same list.
• On the next visit, a blue banner appears at the top of the form:

“You have an unsaved draft from [date/time]. Would you like to continue where you left off?”

• The draft is cleared automatically when the form is saved successfully, or after 7 days of inactivity.

2. What gets restored

Text, numbers, dates, choices, lookups, managed metadata, and people pickers are all restored on Resume draft.

Current limitation: people-picker values are restored as display-only in this version (the visual chips reappear, but you may need to re-confirm the picker before save in some cases). All other field types restore fully editable.

3. Notes

• This applies to new forms only — there is nothing to draft for edit/display forms.
• Nothing is sent to SharePoint; the draft lives entirely in the user’s own browser (local storage). Clearing browser data removes it.
• Because it’s per-browser and per-user, a draft started on one device won’t appear on another.
• No configuration is required — the feature is on by default.

4. Saves that do reach SharePoint — and your flows

The browser draft above never touches SharePoint. Two other save types do, and they are easy to confuse with it:

• Quick save — the user saves without closing the form. The item is written to SharePoint and the form stays open.
• Auto save — the automatic save interval writes the item to SharePoint while the user is still filling it in.

Both are real list writes, so a Power Automate flow using the standard “When an item is created or modified” trigger fires on every intermediate save — long before the user has finished.

Add an optional DFFSSaveType column to the list and DFFS records how each item was saved (save, saveandedit, quicksave, autosave), so a flow trigger condition can run only on a real, final save:

@equals(triggerOutputs()?['body/DFFSSaveType'], 'save')

See the System fields reference for the full value table, how to create the column, and the pattern for flows that write back to the item.