Comment on page
Deploying
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
Here, you can choose which environment to deploy your changes to, add a note about the deployment changes, and whether to supersede existing variants.
Enterprise customers have access to two deployment environments by default - Production and Staging - with the option to create more.
Once you deploy, a Variant revision published event will be sent if you have any configured subscriptions, and a new variant revision uuid will be created.
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.
Whenever a variant is deployed or redeployed to any environment (production, staging, etc...), a 36-character
variant_revision_uuid is created for that deployment to identify the state the variant is in. These variant revision UUIDs can be found in the History tab of the variant.A
variant_revision_uuid is 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
responder_uuid or variant_revision_uuid is 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".
If you would like ensure returning responders do not load deprecated variants, see our redirect to URL section in archiving flows.
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!
Last modified 2mo ago