Form versions
Forms change. You reword a question, add a page, drop a field that wasn't earning its place. The problem that creates is in your results: if a response is shown against today's form, an answer given six weeks ago gets read under a question that no longer exists — or worse, under a different question that happens to sit in the same spot.
big solves that by keeping a version of your form every time its questions change, and stamping each response with the version it was answered on.
How versions are created
- Saving changes to your form's questions creates a new version automatically and makes it live. You don't have to remember to snapshot anything.
- Renaming the form or changing its status doesn't create a version — nothing about the questions changed.
- Saving without making changes creates nothing.
- Changes from the CLI, the API or a connected agent create a version the same way. One limit applies there: they can't rewrite the questions of a live form. A token that tries is refused and told to send the new questions together with a move back to draft, then publish the new version, which asks a person to approve it. A live form's title and display mode are locked the same way (
live_form_locked): take it back to draft first, or rename it in the dashboard. Turning identity syncing on or off still works on a live form. - Re-importing from Typeform creates a version too, and never overwrites in place. If the form has picked up pages, branching or a custom thank-you screen in big since it was imported, the re-import is refused rather than flattening them back into Typeform's single list of fields.
- Save as version does the same thing as a normal save, but lets you give the version a name — "before the spring rewrite", "short version for stories" — so you can find it later.
Versions are numbered in order (v1, v2, v3…) and named ones show their label alongside.
Going back to an older version
Open the version list on your form and choose Set active. That version's questions become the live form immediately, and anyone who opens your public link from that moment sees them. You can do the same from the CLI or an agent, with one extra step on a live form — see From the CLI, the API or an agent.
Setting an old version active doesn't erase anything in between — those versions stay in the list, and the responses collected under them stay attached to them.
Duplicate version copies an older version into a new one without making it live. Use that when you want to build on an old draft: duplicate it, edit it, then set it active when you're happy.
From the CLI, the API or an agent
Everything the version list does in the dashboard also works from the CLI and the local MCP server (big mcp), with the editor role:
| What | CLI | Local MCP | REST |
|---|---|---|---|
| List versions, the active one marked | big form:versions <id> | big_form_versions | GET /api/forms/:id/versions |
| Save as version with a name | big form:version:save <id> --name "<name>" | big_form_version_save | POST /api/forms/:id/versions |
| Duplicate version (the copy is not active) | big form:version:duplicate <id> <versionId> | big_form_version_duplicate | POST /api/forms/:id/versions/:versionId/duplicate |
| Set active — roll back or forward | big form:version:activate <id> <versionId> | big_form_version_activate | POST /api/forms/:id/versions/:versionId/activate |
The remote MCP server reads the list (list_form_versions) and changes nothing. The writes need the forms:write scope; see the API reference.
Setting a version active on a live form needs a person. From the dashboard it is one click, because you are the person. From the CLI, the API or an agent, it is refused with live_form_schema_locked, because it would change what visitors see with nobody approving it. Take the form back to draft, set the version active, then publish it — the publish asks someone signed into big to enter a code:
big form:unpublish <id> --to draft
big form:version:activate <id> <versionId>
big form:publish <id> --version <versionId>On a draft or closed form, big form:version:activate switches at once. Saving and duplicating never change what visitors see, so they work on a live form too.
A version isn't the same thing as publishing
The two are easy to run together, and they answer different questions:
- A version is a snapshot of your questions — what was asked, so an answer is always read under the question it was given for. Saving a change to the questions makes a new one.
- Publishing is about whether the form is reachable at all:
draft,activeorclosed, on the/f/link. It says nothing about which questions are live.
A form can go through ten versions while never leaving draft, and a live form keeps the same public link across every version it has ever had.
One thing follows from that split. Taking a form live from outside the dashboard now needs a person. The CLI, the API and a connected AI agent can ask to publish a form, and the request produces a short code that someone signed into big has to enter before the form goes live — the same approval a link page needs, for the same reason. The code is entered on the form's own Approve a form publish screen (/forms/<form>/approve), which lists every question of the version that would go live; a code typed anywhere else approves nothing. In the dashboard it stays one click: you are already the person the code would have gone looking for. Setting a different version active isn't publishing and doesn't ask for a code in the dashboard — it changes the questions on a form whose status you already chose. From outside the dashboard, doing it on a live form goes through draft and a publish, so it does ask for one.
What this means for your results
- Responses show which version each person answered. A question that didn't exist in someone's version is shown as not asked — clearly different from a question they were asked and left blank.
- Stats can be read per version, so you can answer the question that actually matters: did the change help? Shorten a form from five pages to three and you can compare the finish rate before and after, instead of averaging two different forms together.
- Drop-off is tracked per version too. Since pages get added and reordered, drop-off numbers pinned to a version stay meaningful — otherwise editing a form would silently rewrite the history of every number.
Your public link never changes
Versioning is invisible to the people filling in your form. Your /f/ link stays the same, it always shows the live version, and switching versions doesn't break a link you've already shared.
Good to know
- Versions are read-only snapshots. You edit the live form; you don't edit an old version in place. To change an old one, duplicate it first.
- A version can't be deleted on its own. Every version stays in the list for as long as the form exists, so every response keeps the questions it was answered on.
- Existing forms already have a v1. Everything created before versioning was added is recorded as v1, and every response already collected is attached to it.
- Deleting the form does delete everything. Every version, every response, the whole funnel history. That is the one action on a form that erases what it has collected, and it can't be undone — see Delete a form.
Form stats
Your funnel, where people drop off, and how each number is counted.
Typeform
Import a Typeform form into big, choose which Typeform forms send their new responses to big, back-fill their past responses, mark forms your existing clients fill in, choose which answers reach Notion, and use a Typeform form for coaching client check-ins.