Forms · Glossary

What is form versioning?

Form versioning means keeping each published state of a form as a separate, numbered version rather than overwriting the last one. Every response can then be tied to the exact wording, options and settings the person saw. Editing continues in a draft, and publishing decides which version the live link serves.

Forms change after they go live, often within days, and a changed question quietly breaks every comparison with the answers collected before it. Versioning is what lets you improve a form and still explain your data afterwards.

Nuwan Madhusanka · Co-founder

6 min read · Published 13 September 2026

Draft, version and live link
Question	Draft	Version	Live link
What it is	The copy being edited	A snapshot made when publishing	The address people open
Who sees it	Only the people building the form	Anyone sent its own version address, subject to its access settings	Everyone with the link
Changes when you save an edit	Yes	No	No
Changes when you publish	Its content becomes a version	A new one is added, or the current one is updated	Serves the current version
Carries access settings	Being edited	Its own copy	Those of the current version
Linked to responses	No	Each response keeps its version number	Through the version it served

Why a changed question needs a record

An answer means something only next to the question it replied to. Pew Research Center's guidance on questionnaire design is explicit that measuring change over time requires the same question wording, and even sensitivity to where a question sits in the questionnaire, because earlier questions set the context for later ones. AAPOR's Transparency Initiative asks survey organisations to disclose the exact wording and presentation of the questions behind any reported result, together with the dates of data collection. A form tool that overwrites each edit makes both impossible after the fact. Versioning keeps the questions that were live on each date, so a result can always be put back beside the wording that produced it.

A fix or a new version

Not every edit needs a new version. Correcting a spelling mistake, tidying a help sentence or changing a colour does not change what an answer means, and updating the current version in place keeps the history uncluttered. A change that alters meaning does need one: rewording a question, adding or removing an option, changing a scale, moving a question to a different section, or making a field required. Reordering options belongs in the second group too, because the position of an option affects how often it is chosen. When unsure, ask whether you would have to explain the change to somebody comparing this month's results with last month's.

What a version should hold

A useful version records everything that could change an answer or who gave it. That means the questions with their exact wording, options, order and required flags, any routing between them, and the access settings in force, since a form that was public last week and restricted this week has been answered by different groups. It should also carry when it was published and by whom. Visual design matters less for the data, but a version that keeps the layout lets you show somebody precisely the screen they saw, which settles more disputes than any description of it. Keep versions permanent as well. A history that can be edited or pruned stops being evidence of what was asked, and the answers that point at a removed version lose the questions that explain them.

Test the version before people answer it

AAPOR's best practice guidance puts the principle in one line, if you want to measure change, don't change the measure, and it pairs that with a second habit: pretest a questionnaire with people similar to those who will answer it before it goes into the field. Both apply to every new version. Before publishing, have somebody outside the project fill in the draft on a phone and say aloud what each changed question is asking. After publishing, submit one test response, confirm it lands with the new version number and the columns you expect, then delete it so it does not reach the results.

Reading results that span versions

Export the responses with the version attached and look at each version as its own group before combining anything. Questions whose wording and options never changed can be pooled. Questions that did change should be reported separately, or merged only with a note explaining what moved. Expect columns that are empty for some rows, because a question added in a later version was never asked of earlier respondents, and an empty cell there is not a skipped answer. Keep a short change log beside the export as well; a version records what changed, but rarely why.

Versions in the form builder

Publishing writes a version, and each version carries its own access settings: the access type, the secret key, the allowed emails and the allowed domains. The Publish tab offers two actions, Publish New Version and Update Current Version, so a fix can go live without starting a new version. Saving in the builder changes the draft only, and the live link keeps serving the current published version, which also means a change to who can open the form takes effect only when it is published. An older version stays reachable at its own address, /:slug/v/:versionUuid, and every response keeps the version number it was submitted against.

Questions people ask

Does publishing a new version delete earlier responses?

It should not, and in a well designed tool it does not. Responses are stored separately from the form and remember which version they came from, so new respondents see the new questions while earlier answers stay readable against the questions they replied to. Check this before relying on a tool, by publishing a small change to a test form.

Should respondents be told a form has changed?

Only when it affects them. Somebody who already submitted does not need to know about a reworded question for new respondents. If the change fixes something that made earlier answers wrong, such as a missing option, it is worth contacting those people with a short note and a way to add the missing information, rather than asking them to fill in everything again.

Is versioning the same as undo history?

No. Undo history records every small edit while a form is being built, and it usually disappears when the session ends. Versions are deliberate snapshots made when the form is published, and they last. A day of editing can produce hundreds of undo steps and a single version, which is the point: versions mark the states that people actually answered.

How should a report refer to versions?

By date as well as number, since readers understand dates. A line such as responses collected between 3 and 17 March on version 2, and from 18 March on version 3, with the changed question named, is enough. Put it near the chart it affects, not in an appendix, so nobody reads a shift in the results without seeing the reason.

Can two versions of a form run at the same time?

One version is current and served by the live link, while an older one can still be opened at its own address. That is useful for showing somebody the form they answered, but it is not a proper way to compare two designs. For a real comparison, build two separate forms and send each to a comparable, randomly chosen group.

Who should be allowed to publish a new version?

As few people as the work allows. Every publish changes what respondents see and what the data means, so publishing belongs with whoever is accountable for the results. On a team, agree that changes are drafted by anyone but published by one owner, with a line in the change log naming what changed and why.

Make one with forms

The button opens the generator with this use case already described. Change the wording to match your own.

Create a form with OneCraft

Sources

Written and checked by the OneCraft team. Last checked 13 September 2026.