Versioning in Formsort (Deploying)

Deploying Your Flow

Before your responders can interact with your form, it needs to be deployed. Deployment is the final step that makes your latest changes live and accessible, and also creates a variant revision of your form.

💡Deploying a variant to any environment (e.g., Production, Staging) creates a unique 36-character variant_revision_uuid. This UUID represents the exact state of the variant at the time of deployment and can be found in the History tab of the variant.

In this section, we'll walk through how to deploy your form, and cover the configuration options available during deployment—like selecting environments, adding deployment notes, and managing variant revisions.

Deployment Workflow

To make your flow updates visible to responders, click Deploy at the top right of the flow editor. If the flow has already been deployed before, the button will read Redeploy.

During deployment, you can:

• Select the environment you want to deploy to (e.g., Production, Staging)

• Add a note describing the changes in this deployment

• Enable superseding of existing variants (to replace older versions)

Enterprise customers have access to multiple deployment environments (e.g., Production and Staging) and can create additional environments as needed.

Once deployment is complete:

• A new variant revision will be created
• If you’ve set up Subscriptions, a Variant revision published event will be sent to the specified endpoint

No in-studio changes will go live until the variant is explicitly re-deployed to the production environment. This includes changes to:

• Theme and styling

• Logic and variables

• Third-party integrations

Drafts and Deployment

Before a flow is deployed, it exists as a draft—only visible in the preview window to Studio users who are signed in to Formsort. Drafts are not accessible to the public.

Once you make a deployment, the flow becomes live and publicly accessible—unless access is restricted with authentication settings.

Any edits made after deployment will not be reflected in the live version until you re-deploy those changes.

After deployment, you can revert to previous revisions.

To learn more, see the Managing Revisions section.

---

Superceding past revisions of a variant

When publishing a variant, you can choose to Supersede past revisions. This setting forces responders who started on an older revision of the same variant to load the latest version the next time they return.

This is especially useful when:

• Fixing logic or content errors

• Updating the design or copy of an active variant

Superseding only applies to responders pinned to an older revision of the same variant. It does not affect responders who were on a different variant entirely.

Behavior of Returning Responders

When a superseding revision is loaded by a returning responder:

• They will be taken to the beginning of the flow

• Their previous progress will not be restored

We may offer more granular control over this behavior in the future—for now, assume superseding will reset in-progress sessions.