Variant revisions
Last updated
Was this helpful?
Last updated
Was this helpful?
When you or redeploy a variant to any environment (e.g., Production or Staging), Formsort 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.
When a responder loads a flow and begins interacting with it, a variant_revision_uuid will be loaded based on the responder_uuid cached in their browser. This “pins” the responder to that exact variant revision on return visits, ensuring a consistent experience in terms of content, style, and logic.
This pinning behavior helps maintain:
A seamless experience for returning users
Cleaner cohort analysis, since responders in-flight on older revisions won’t be affected by new deployments
To bring responders onto the latest revision, see .
There are two main ways to bypass variant pinning:
Enable Start each session as a new responder in your variant settings
Use your browser’s incognito mode, which doesn’t store responder_uuid during incognito sessions
If you’re troubleshooting and want to confirm which variant revision is cached:
Open your live flow.
Right-click anywhere and select Inspect to open your browser's developer tools.
Go to the Network tab.
Look for a fetch request with the name of the variant deployment ID.
In that request, you’ll find the variant_revision_uuid.
You may need to reload the page after opening the Network tab—the fetch call is made once when the flow initially loads.
If you need to test or share an exact revision, append the variantRevisionUuid parameter to your form’s URL:
Replace YOUR_UUID_HERE with the target revision’s variant_revision_uuid.
