Last updated
Last updated
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.
Here you can:
add a note about the deployment changes
No in-studio changes to flows or variants will be "live" until the variant is re-deployed to the production environment. This includes Theme changes, changes to logic and variables, and changes to integrations.
We refer to this as "pinning" a user, and it allows for logical and visual continuity of the end user experience while also providing 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 two ways:
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 revision of your form but keep getting old revisions loaded because you are pinned, navigate to the form in an incognito window!
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.
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!
choose which your changes will be deployed to
enable of existing variants
customers have access to alternate deployment environments by default - Production and Staging - with the option to create more.
Once the form is deployed, a new variant revision uuid will be created. If you have any configured , a Variant revision published event will be sent to that endpoint.
Whenever a variant is deployed or redeployed to any (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 tab of the .
A variant_revision_uuid is cached in a responder's browser once they load a form and begin interacting with it, exactly like a . 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.
To bring returning responders on to the most up-to-date revision of your variant, see below.
By enabling
If you would like ensure returning responders do not load deprecated variants, see our redirect to URL section in .
Deploying a Formsort flow to the world.
