Form versions
introduction sparklayer forms uses versioning so you can safely update forms without interrupting live customer submissions every change you make creates a new version behind the scenes β letting you test updates before publishing them live π version states each form version has a clear status state what it means draft work in progress changes not visible to customers published the live version used for new submissions archived older versions kept for reference and historical entries only one version can be published at a time, and only one draft can exist per form βοΈ how versions work the form builder interface has a version switcher ui at the top right of the page version switcher the version switcher allows easily switching between draft version (editing) this is where you can make any changes and preview the form before making the changes live to all users published version (read only) this is the live version used for forms embedded on your store published version is read only creating a draft when you edit a form a draft version is created from the current published version your changes save automatically the live form remains unchanged this lets you experiment without affecting customers publishing changes when you click publish select what areas you want to publish changes to form fields the main form users will see internal fields administrative internal fields against submissions workflows automation setup and logic the draft becomes the new published version the previous published version moves to archived all new submissions use the latest version existing submissions are not modified preview before publishing you can preview a draft to test changes safely opens a preview of the form lets you test validation and logic preview entries are marked separately use preview mode whenever you change structure, logic, or workflows π how versions affect submissions understanding this helps avoid data issues when updating forms new submissions always use the current published version follow that versionβs fields, validation, and workflows existing submissions keep the version they were created with retain their original data structure continue to work with the workflows from that version in progress submissions if someone started filling out a form before you published changes they continue on the version they began with theyβll only see updates when starting a new submission π‘ best practices where possible, publish changes to all affected areas in one go (form fields, internal fields and workflows) provide a clear changes summary in the publish dialog this is useful for audit purposes in the future test new versions before sharing publicly if you want to completely rethink and rework a form, it is often better to make a new form rather than edit an existing one