FormWork keeps form versions and entry history as separate concepts. A form version holds the questions, rules and settings respondents see. An entry’s history records what happened to that entry afterwards: corrections, team field changes, stage moves, approvals and automation runs. Together, they explain both what a form asked and how a response was handled.
Example: changing an application process
Suppose version 1 asks applicants for three pieces of information. Your team decides that future applications also need supporting evidence.
- Edit the form. The builder works on a draft while respondents keep using the published version.
- Add the evidence field and its validation, then preview the draft.
- Select Publish. The review lists what will change, grouped into form settings, pages and fields, process, automations and team fields, and asks about anything that affects existing entries.
- Publish. New entries use the new version. Entries already started, including ones still in progress, keep the questions they were started with.
This avoids silently adding a new requirement to an older entry. It does not migrate existing answers into the new structure.
What follows the version, and what doesn’t
The respondent’s answers stay with the version they were given. Everything your team uses to work on an entry follows the latest published version:
| Part | Follows |
|---|---|
| Questions, conditions and validation the respondent saw | The version the entry was started on |
| Team fields, the process and automations | The latest published version |
| Notifications and views | The form’s current settings, which aren’t versioned |
So a fixed automation or a new stage applies to every entry from the next event onwards, old or new. When you change the process or an automation that has entries or runs waiting, the publish review asks what should happen to them, for example which stage to move entries to when you remove a stage. See drafts and publishing.
Draft, published and archived versions
A form has at most one draft and one published version. Publishing replaces the published version, and the one it replaces is archived. Archived versions can’t be previewed. The publish review compares the draft with what is live; there is no general comparison or restore tool for arbitrary archived versions. To undo a published change, make the change again in a draft and publish it.
Previews create isolated test entries and run automations with external effects stubbed. They don’t send emails, contact other systems or change real entries. Test entries stay out of normal lists, counts and exports and are removed a day after their last change. Shareable draft preview links work without sign-in for an hour. See Preview.
Inspect what happened to an entry
Each entry’s history lists everything in one timeline: the submission, answer corrections with who made them and why, team field changes, stage moves and owner changes, approval requests and decisions, and automation runs. It can be filtered by kind and can’t be edited.
History is not a one-click restore feature. To put back an earlier answer, read it in the history and save it again; the correction is added to the history.
Read the drafts and publishing guide for the exact lifecycle, or see how versions fit into an application review process.