Comment on page
Deploying a Formsort flow to the world.
To deploy a flow, making your changes visible to responders who are sent to it, click Deploy at the top right of the flow editor. If you've already published the flow you are editing, the button will instead show Redeploy.
The deploy menu
No in-studio changes to flows or variants will be live until they are re-deployed. This includes styling changes, changes to logic and variables, as well as changes to integrations. For any change to a flow or variant whatsoever to go live, a flow must be re-deployed.
variant_revision_uuidis cached in a responder's browser once they load a form, much like a ResponderUUID. This forces the the same variant and variant revision to be loaded upon return visits, which ensures the responder will see the same content, style, and logic as they did when they first visited.
This is called "pinning" and allows for logical and visual continuity of the end user experience, and gives you more useful cohorts for analysis: deploying a new version will not affect the experience of responders that are in-flight on an older version.
Pinning can be circumvented by loading a form in your browser's incognito window. No
variant_revision_uuidis stored in an incognito session.
Pro-tip: If you are trying to test the most up-to-date revisions of your form but keep seeing old revisions get loaded, navigate to the form in an incognito window!
To bring returning responders on to the most up-to-date revision of your variant, see superseding existing versions below.
By enabling supercede past revisions of variant? when you publish, you will force responders who started on an older revision of your variant onto the newest revision being published.
Superceding on deployment is useful for pushing fixes to content or logic errors or updating content and styling. Keep in mind, however, that superceding will not bring responders who have visited a different variant onto the newest revision of a variant that is "superceding on deployment".
Currently, when a flow is superseded, a returning responder will have to start from the beginning.
We may change this in the future, providing more control over what to do with returning responder data, but keep this in mind for now.
It is possible to check which flow variant and variant revision is cached, by poking around your browser. It takes a little digging, but it's a pretty simple process!
With your live flow pulled up in a regular browser window (not incognito), right click + inspect.
When the sidebar window opens, click Console, paste in the following code, and press Enter.
localStorage.getItem('LOCALSTORAGE_VARIANT_UUIDS_KEY') || sessionStorage.getItem('STORAGE_VARIANT_UUIDS_KEY')
You will see that a variant label is returned, as well as the variant_revision_uuid and the environment the variant was deployed to.
Depending on how many flows have been cached, you may see several different variants listed!