Formsort
Search…
Building flows
Handling data
Deployment workflow
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 published the flow you are editing before, the button will instead show Re-deploy.
The deployment dialog
Here, you can choose which environment your changes will be deployed to, add a note, and whether to supersede existing variants.
This will trigger the Variant revision published event to be sent, if you have any configured subscriptions.
No changes to flows or variants will be enacted 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.
Superseding existing versions
Responders are pinned to the version of your flow that they saw when they first visited. When a responder returns to a flow that they started previously, they will see the same content, styles, and logic as when they first visited.
This pinning allows for logical and visual continuity for the end user experience, and gives you more useful cohorts for analysis: publishing a new version will not affect the experience of responders that are in-flight on an older version.
By superseding when you publish, you will force everyone, including responders who started on older version of your flow, onto the new version that you are publishing.
Generally, you should not supersede on deployment: use this for situations where you had a content or logic error in an existing version that was live, and you do not want responders staying on old versions.
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.
Last modified 1yr ago
Copy link
Contents
Superseding existing versions