How E-form Data is Managed

Every value a user types into an E-form can end up in three different places: the Document that the form is saved as, the Record that Document belongs to, and a behind-the-scenes list called Form Data. Understanding which of those places a value lands in — and which of them a field reads from when the form opens — is the key to designing forms that behave the way you expect.

The Three Storage Locations

Document Data is the snapshot of what was entered on that particular form. Every filled-in E-form is saved as a Document, and the values are stored with it. This is a permanent record of what that form said at the moment it was saved, and it does not change when other forms are filled out later.

Record Data is the shared index data for the Record itself — the values you see on the Record screen, search on, and use in workflows, merge templates, and variables. There is only one value per field name on a Record, so the newest save wins.

Form Data is a hidden per-Record list that remembers the last value saved for each field name from any E-form in that Record. It is not visible or editable anywhere in the system, and it exists for one purpose: to pre-fill fields on new forms started in that same Record. Because it is stored separately from Documents, deleting or purging a Document does not erase the Form Data values that Document contributed.

How Data Is Saved

When an E-form is saved, each field is written out as follows.

The Document always gets the value. This happens for every data-holding field regardless of any other setting. A field that is not set to "Save to Record" is not excluded from the Document — it is excluded from the Record.

The Record gets the value only if "Save to Record" is turned on for that field. If "Requires Approval" is also turned on, the value is held back from the Record until the form is approved; the Document and Form Data are still written immediately.

Form Data always gets the value. The entry for that field name is overwritten with the value just saved, so Form Data always reflects the most recent save for that name anywhere in the Record.

Two behaviors are worth calling out because they surprise people:

• Blanking a field clears the Record value. When a form is saved, any Record data element whose value is now empty is removed from the Record. The Document still holds the empty value, but the Record no longer carries that field.

Table fields are the one exception to "the Document always gets it": table data is written to the Record or the Document, never both. With "Save to Record" on, the rows go to the Record — as true line items if "Line Item Table" is on, otherwise as table-tagged data elements. With it off, the rows stay on the Document.

How Data Is Populated

Two settings on each field, both under Data Settings → Data Handling, control where a field gets its starting value.

"Where to Get Initial/Latest Value" chooses the source:

"Always Use Latest Record / Form Value" chooses when that lookup runs:

• Off (the default) — the lookup runs only when the form is brand new. Once the form has been saved as a Document, reopening it shows exactly what was saved on it. The form is a fixed snapshot.
• On — the lookup runs every time the form is opened, even on an already-saved Document. The previously saved value is discarded and replaced with the current value from the Record or Form Data. Use this for forms that display live status: a status form that should always show where the Record stands today, not where it stood when the form was filled out.

A third switch, "Always Use Document Data Value," applies only to already-saved forms with "Always Use Latest Record / Form Value" turned off. It reloads the field from the Document's own data elements each time the form opens, which lets outside processes — workflow actions, imports, API updates — change what an existing form displays without routing that change through the Record.

Signature fields are deliberately excluded from most of this. A signature is never auto-populated on a new form, and is only refreshed on an existing form when a lookup setting explicitly demands it, so that a captured signature is not silently copied onto a form the signer never saw.

Choosing the Right Combination

A normal data entry field that should remember what the user last entered: turn on "Save to Record", set "Where to Get Initial/Latest Value" to Record / Form Data, and leave "Always Use Latest" off. New forms pre-fill from the Record, saved forms stay as they were filled out.

A field that always shows the Record's current state: turn on "Always Use Latest Record / Form Value" and set the source to Record Data Only. Every time anyone opens the form — old or new — the field reflects the Record as it is right now.

A calculated or computed field: set "Where to Get Initial/Latest Value" to "Do Not Set Value / Compute Value" and leave the "Always Use Latest" switches off. Any loaded value would overwrite the calculation. The E-form editor detects this conflict and offers a "Fix Settings" button when a computing field has lookup settings that would cancel its calculation out.

A field the user must fill in fresh each time (a date of signature, a reading, a count): set the source to "Do Not Set Value / Compute Value" so nothing carries over from the previous form.

Sensitive data on a public form: the "Allow Save for Later" switch controls whether a field's value is stored on the visitor's device when they save an incomplete public form. Turn it off for Social Security numbers, account numbers, and similar data.