# 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](https://docs.formsort.com/core-concepts/versioning-in-formsort-deploying/variant-revisions) of your form.&#x20;

{% hint style="info" %}
:bulb: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.
{% endhint %}

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**.

<div align="left"><figure><img src="https://1036686854-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJPnL__mOdr_mLZ8nwf%2Fuploads%2FzP0rQoJGjSXEjqpd9lM7%2Fimage.png?alt=media&#x26;token=3ea4b714-91f2-4fe2-95ff-2ca0c2488903" alt=""><figcaption></figcaption></figure></div>

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)

{% hint style="info" %}
Enterprise customers have access to multiple deployment environments (e.g., Production and Staging) and can create additional environments as needed.
{% endhint %}

Once deployment is complete:

* A new [variant revision](https://docs.formsort.com/core-concepts/versioning-in-formsort-deploying/variant-revisions) will be created
* If you’ve set up [Subscriptions](https://docs.formsort.com/event-subscriptions), a **Variant revision published** event will be sent to the specified endpoint

{% hint style="warning" %}
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
  {% endhint %}

### Drafts and Deployment

Before a flow is deployed, it exists as a **draft**—only visible in the [**preview window**](https://docs.formsort.com/publishing-and-deployment/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.

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.&#x20;

To learn more, see the [Managing Revisions](https://docs.formsort.com/core-concepts/versioning-in-formsort-deploying/managing-revisions) section.

***

### Superseding 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.

<figure><img src="https://1036686854-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJPnL__mOdr_mLZ8nwf%2Fuploads%2FRYgrN6dE3ozGIneQddIg%2Fimage.png?alt=media&#x26;token=d8521b91-dea3-48a2-bd2f-e4293dfb1b63" alt=""><figcaption></figcaption></figure>

This is especially useful when:

* Fixing logic or content errors
* Updating the design or copy of an active variant

{% hint style="warning" %}
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*.
{% endhint %}

#### 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.
