Editing a live survey

Editing a survey that is already out in the world is safe, and it is worth understanding why: every distribution is pinned to a fixed version of your survey. People answering through that distribution always see the survey exactly as it was when you created it — your later edits are invisible to them.

That means you can keep working on a survey while responses are coming in, without any risk of changing the questionnaire underneath someone who is halfway through it.

How versions and distributions fit together

While you edit, you are changing the survey’s working copy. Nothing that is already distributed moves.
When you create a distribution, Indacas takes a snapshot of the survey as it stands and pins the distribution to that version. The version number appears on each distribution, shown as v1, v2 and so on.
Every response inherits its distribution’s version, so a response always renders the questionnaire that person was actually given — including responses started before an edit and finished after it.

Getting your changes out to people

Since existing distributions never move to a new version, edits reach respondents in one of two ways:

Create a new distribution. This snapshots your current version of the survey and pins the new distribution to it. Anyone using the new link or invite gets your updated questions; anyone still using the old distribution carries on with the old ones.
Use automatic distributions. Scheduled distributions pick up the latest version each time they fire, so recurring waves stay current without you doing anything.

If you want everyone on the new wording, create the new distribution and expire the old one.

Previewing shows your edits

Preview runs your current working copy by default — that is what makes it useful for checking edits before they go out. The preview page’s version picker can also replay any sealed version, which is the quickest way to see exactly what a respondent on an earlier version is seeing. If a preview looks different from what a respondent describes, check the version number on their distribution.

Version history

The Versions page lists every version with its change description and lets you compare any two. You can also:

Create a named version yourself before a significant round of edits, with a description of what you are about to change (“Before shortening wave-2 screener”).
Revert to an earlier version. The working copy is replaced with that version’s content, and the revert is saved as a new version, so nothing is lost in either direction. Reverting does not disturb existing distributions — they stay pinned where they were.

Deleting a question is also safe for your data: it is retired rather than erased, so responses collected on earlier versions still display correctly.

Keeping your data comparable

Because respondents are protected from mid-flight changes, the real question when editing is not safety but comparability — whether you will be able to pool answers across versions when you analyse.

Straightforward to change:

Fixing typos and rewording for clarity, where the question still asks the same thing
Updating descriptions, help text and page titles
Adding new questions or choices

Worth thinking twice about, because they split your dataset:

Rewording a question so it means something different — the same column now holds answers to two different questions.
Changing choice values or scale ranges — a “3” before and after the change are not the same “3”.
Removing questions or choices — later respondents have no value where earlier ones did.
Reworking logic rules — respondents take different paths, so who was asked what changes.

If you need one of these mid-collection, note which version introduced it. Each response records its version, so you can split or filter your analysis at exactly that boundary.