Forms
Update a live form without breaking its link
Once a link is out in the world you cannot take it back, which makes editing a live form feel risky. It is not: saving only writes the draft, and the link keeps serving the last published version until you deliberately publish again.
Two copies, one link
The form you edit is the draft. The form the link serves is the published version. They are separate records, and saving in the builder only writes the draft. That is why you can rewrite half a form during a campaign without anybody seeing a broken state, and it is why an edit you made yesterday might not be live yet.
Update in place, or publish a new version
Publishing offers two paths. Updating the current version in place changes what the link serves and keeps one version number. Publishing a new version leaves the old snapshot intact and makes the new one current. Neither changes the link itself, so the choice is only about how much history you want to keep.
Which one to pick
Update in place for anything that does not change what a response means: fixing a typo, clearing up a help text, swapping the theme. Publish a new version whenever old and new responses would answer different questions, which covers adding a required field, changing what an option means, or restructuring a section. That way the version number in your data explains the difference later.
The part people forget
Access settings are published with the version. So if you change a form from public to key protected and only save, the live link is still public. Any change to who can open a form needs a publish before it takes effect.
How it works, in three steps
Step 1
Edit freely
Saving writes the draft. The live link is untouched however much you change.
Step 2
Choose in place or new version
In place for wording and design. A new version whenever the meaning of a response would change.
Step 3
Publish, and check the access type
Access settings travel with the version, so confirm the published version has the access you meant.
The full walkthrough with screenshots is in the guide Publish updates without breaking your live link.
Limits worth knowing
- Saving does not make anything live. Publishing does.
- Access settings are part of the published version, so an access change needs a publish.
- The draft is a single working copy, not a history. Only published versions are kept.
See it on a finished piece
Questions people ask
Will editing a live form break the link I already sent?
No. The link serves the published version, and editing only writes the draft. The link itself never changes.
When should I publish a new version instead of updating?
Whenever a response collected before the change would mean something different afterwards. Adding a required field or changing what an option means both qualify.
I changed the access type and nothing happened. Why?
Access settings are stored with the published version. Publish the form and the live link picks them up.
Make your own form
The button opens the generator with this use case already described. Change the wording to match yours, generate, then edit anything you like.
Create a form with OneCraftRelated pages
Form version history
Publishing does not overwrite. Each publish writes a version holding the whole form as it stood, including its access settings, and one of those versions is marked current. Rolling back means making a different one current.
Forms only your people can open
Login required is the access type for when it matters who answered. A respondent has to be signed in, and you can limit that to a list of addresses or to everybody on a domain.
Generate a form from a description
The same request written three ways produces three different forms. This page is about that gap: what a vague prompt gives you, what naming your sections adds, and what happens when you paste the questions you already have.
More finished work of this kind is on the form examples hub.