Deploying
Deploying a Formsort flow to the world.
Last updated
Deploying a Formsort flow to the world.
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:
choose which environment your changes will be deployed to
add a note about the deployment changes
enable superseding of existing variants
Enterprise 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 subscriptions, a Variant revision published event will be sent to that endpoint.
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.
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 and begin interacting with it, exactly 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.
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.
To bring returning responders on to the most up-to-date revision of your variant, see superseding existing versions below.
Pinning can be circumvented two ways:
By enabling start each session as a new responder
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".
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.
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!
