System fields

Modern DFFS recognizes a small set of optional list columns. If a column with one of these internal names exists in your list, DFFS fills it in automatically on save. If it doesn’t exist, nothing happens — there is no setting to switch on and no penalty for leaving them out. You opt in purely by adding the column.

1. The fields

Why do two of them start with an underscore? Purely for backwards compatibility with Classic DFFS, which used those exact names. New system fields drop the underscore — which is why the newest one is DFFSSaveType and not _DFFSSaveType. The underscore carries a real cost (see the next section), so there is no reason to repeat it in new work.

2. Creating the columns

Columns without a leading underscore

Add a Single line of text column and name it exactly DFFSSaveType — no spaces. The modern Add column UI is fine for this.

SharePoint derives the internal name from the name you give the column at creation time, so “DFFS Save Type” would become DFFS_x0020_Save_x0020_Type and DFFS would never find it. Once the column exists you can rename the display name to anything you like — the internal name stays put.

Columns with a leading underscore

The modern list UI cannot create these. Adding a column called _DFFSID from the + Add column button in the list view will not produce the internal name _DFFSID. You must create it from List settings instead.

1. Open the list, then Settings (gear) → List settings.
2. Under Columns, choose Create column.
3. Type the name exactly — _DFFSID or _vLookupID — and pick Single line of text.
4. Save. Verify the internal name by opening the column again and reading the Field= parameter at the end of the browser’s address bar.

The same applies to any other tooling that sets the internal name directly (PnP PowerShell, REST, a site column in a template) — the restriction is in the modern Add column UI, not in SharePoint itself.

3. DFFSSaveType — controlling Power Automate flows

Modern DFFS saves the item to SharePoint on a Quick save and on every Auto save tick, not just when the user finishes the form. Any flow using the standard “When an item is created or modified” trigger therefore fires on those intermediate saves too — long before the user is done.

DFFSSaveType gives the flow something to test, so it can tell a real save from an intermediate one:

In the flow, open the trigger’s Settings → Trigger conditions and add a condition so the flow only runs on a real, final save:

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

To run on both save variants:

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

Using a trigger condition rather than a Condition action means no flow run is created at all for the saves you don’t care about — quick saves and autosaves never consume a run.

No OData_ prefix here. SharePoint’s REST/OData layer — which is what Power Automate reads — exposes a field whose internal name starts with an underscore under an OData_ prefix, so _DFFSID arrives as OData__DFFSID. Because DFFSSaveType has no underscore, what you see is what you type.

Two things worth knowing

1. The values are fixed English tokens and will never be localized or renamed. They are part of the API surface your trigger conditions are built on — a form displayed in Norwegian still writes quicksave.
2. The value stays on the item until the next DFFS save. If someone later edits the item in Quick Edit, in a view, or from a script, the field still reads save from the last DFFS save, and the flow triggers again. Where that matters, have the flow’s first action write a different value back (for example processed, or clear the field): the trigger condition then blocks the flow’s own update from re-triggering it, and a later non-DFFS edit won’t match the condition either.

The Misc tab → Save & actions group tells you whether DFFSSaveType was found in the current list, so you can confirm the column was created with the right internal name without leaving the form builder.

Adding the column does not make Quick save or Auto save write to SharePoint any more often than before — the value rides along with a save that was going to happen anyway, and idle autosave ticks are still skipped.

4. _DFFSID and _vLookupID

Both are unique-id columns that DFFS populates automatically when the item is created. Their purpose is to give an item a stable identifier that is available in the form, so it can be copied into a related item — something the built-in ID column can’t do on a NewForm, because SharePoint hasn’t assigned it yet.

_DFFSID

The current one. The value is a timestamp such as 1675185443242. Its most common use is linking a child item back to its parent: when a child is created from the parent’s form, the parent’s _DFFSID is transferred into a plain text column on the child, and that column becomes the relationship. Because it’s ordinary text rather than a lookup, it works even when the two lists live in different sites — see the Repeating Sections guide.

_vLookupID Legacy

Kept for compatibility with Classic DFFS. Classic’s vLookup used a column of this name, in the format userId:timestamp (e.g. 12:1675185443242), and Modern DFFS still auto-populates it so imported configurations and existing lists keep working unchanged.

Don’t add _vLookupID to a new list. It exists so Classic configurations survive the move to Modern DFFS. For anything new, use _DFFSID.

5. Notes

• All three columns are optional. A list without them behaves exactly as it always has.
• DFFS only writes these columns; it never requires them to be visible on the form. Hide them from your views if you’d rather users didn’t see them.
• The internal name is what matters, not the display name. Rename the display name freely after the column exists.