# Introduction to Formsort
## What is Formsort?
[Formsort](https://formsort.com/) is a form builder with the flexibility of code—built for teams who don’t want to wait weeks for small changes, who want the power to make bold updates that drive real business results, and who want full ownership over their outcomes.
### Where it sits
**Formsort is a fully-managed platform for building and hosting forms.**
Your team creates and manages form content using our online Studio—a purpose-built content management system (CMS) designed specifically for forms. From styling to data storage, everything is handled in one place.
We host your fully-branded forms on your subdomain or embedded directly within your site.
Formsort forms are production-ready and designed to integrate seamlessly into your stack—supporting the full lifecycle from rapid prototyping to high-traffic registration flows.
### Who Formsort Is For
* **Startups** looking to launch form flows quickly on infrastructure that scales with them.
* **Growing businesses** aiming to optimize form performance to reduce acquisition costs and increase conversion rates.
* **Enterprises** that want to build form flows for new business lines—without requiring dedicated teams.
* **Teams managing complex internal workflows** that rely on structured data collection.
* **Companies in regulated industries** that need to collect user data securely, without spreading it across multiple platforms.
* **Ambitious product managers and designers** ready to go beyond prototypes and launch form flows to real users.
Once set up, a single non-technical product or business owner can ship sophisticated form flows—without needing help from engineering or design teams.
# Formsort quickstart guides
**Formsort gives you tons of flexibility to build a personalized experience for your responders—and it’s easy to experiment along the way.** Whether you’re adding dynamic content, tailoring questions, or tweaking logic, there are lots of tools at your fingertips.
Explore the guides below to get started:
* [Adding content and collecting answers ](/core-concepts/formsort-quickstart-guides/add-content-and-collect-answers)
* [Capturing demographic data ](/core-concepts/formsort-quickstart-guides/capture-demographic-data)
* [Adding informational content](/core-concepts/formsort-quickstart-guides/add-informational-content)
* [Templating your variables](/core-concepts/formsort-quickstart-guides/template-your-variables)
* [Adding conditional logic](/core-concepts/formsort-quickstart-guides/add-conditional-logic)
* [Using conditional logic with Calculated and API variables](/core-concepts/formsort-quickstart-guides/using-conditional-logic-with-calculated-and-api-variables)
* [Ending your flows](/core-concepts/formsort-quickstart-guides/end-the-flow)
* [Reviewing the variable schema ](/core-concepts/formsort-quickstart-guides/review-your-variable-schema)
* [Setting up Integrations ](/core-concepts/formsort-quickstart-guides/set-up-integrations)
{% hint style="info" %}
💡 Want even more inspiration? Check out our guides on signup flow best practices and client intake form best practices for tips on crafting a polished, high-converting experience.
{% endhint %}
# Add content and collect answers
Add questions, informational text, pictures, and videos to your flow.
### Flow **Content Tab**
* The content tab is where you will add **groups**, **steps**, and **questions** to your flow.
* There are lots of different question types you can choose from. Some question types require answers, while some are purely informational, like pictures or text. See our [component reference](/adding-questions-and-content/question-reference) section for descriptions of different question types.
* When you click on the group, step, or question, you will see the editor on the side. This is where you can manage the **logic** and **settings** of the element you are editing.
* You can use basic **markdown** within the question text itself to format the text style - like assigning header styles that you have created in your Typography menu, bolding or italicizing certain words, or adding links.
* Hit the **Live Preview** to see the flow update with your edits in real time.
Markdown menu
#### Headers
```
# This is a big header
```
## This is a big header
```
## This is a medium header
```
### This is a medium header
```
###### This is the smallest header
```
**This is the smallest header**
#### Emphasis
```
*This text will be italic*
```
*This text will be italic*
```
_This will also be italic_
```
*This will also be italic*
```
**This text will be bold**
```
**This text will be bold**
```
__This will also be bold__
```
**This will also be bold**
```
_These **can** be combined_
```
*These **can** be combined*
#### Lists
```
* Item 1
* Item 2
* Item 2a
* Item 2b
```
* Item 1
* Item 2
* Item 2a
* Item 2b
```
1. Item 1
1. Item 2
1. Item 2a
1. Item 2b
```
1. Item 1
2. Item 2
1. Item 2a
2. Item 2b
#### Links
```
[Formsort](http://formsort.com/)
```
[Formsort](http://formsort.com/)
#### Blockquotes
```
As Dieter Rams said:
> Less, but better
```
As Dieter Rams said:
Less, but better
### Common question types
* [**Select question**](https://docs.formsort.com/building-flows/content-types/select)**:** responders choose from a selection of choices (you can [style your choices](https://docs.formsort.com/building-flows/content-types/select#styling-choices) by adding images or changing the presentation between buttons, dropdown, etc.)
* [**Text question**](https://docs.formsort.com/building-flows/content-types/text): responders enter free text
# Capture demographic data
Learn how to capture the most common types of demographic data from your responder.
## Capturing demographic data
It’s likely that you’ll want to capture some demographic information from your users, such as first and last name, contact information, and any other identifying information that may be relevant to your business. Let’s build a couple steps that will capture basic information from your users.
### Add a step
To start, we’ll want to add a [step](https://docs.formsort.com/building-flows/adding-content/steps). A step can be thought of as a container for questions, and will render as a single “page” that the responder will see.
### Capture name
Now that we have the question container, let’s add some questions to it. The first thing we’ll want to know about a user is their name. [Text components](https://docs.formsort.com/building-flows/content-types/text) are the perfect tool for this since they allow users to enter text freely.
{% hint style="info" %}
Check out [some examples](https://fineflows.com/elements/first-namelast-name) of how others capture first and last name in their flows.
{% endhint %}
The next two steps will apply to every question you create:
* Add a title to the question so the responder understands what the question is asking. As you can see in the gif below, this will automatically update the “Question Label” and the “Variable” sections in the question Settings.
* Be sure to provide a useful variable name in the Variable section. This will be the name of the data value when an answer payload is sent. As a default measure, this box will automatically copy whatever you’ve put as the question title -- it’s probably necessary to rewrite this.
In the text component’s **settings**, you have the option to add **placeholder** **text** for the input box, to provide more clarity and direction for your users.
### Capture phone and email
Next, we may want to capture their phone number and/or email. There are two components we can use for this: [phone](https://docs.formsort.com/building-flows/content-types/phone) and [email](https://docs.formsort.com/building-flows/content-types/email). Pretty simple!
#### Phone
Add a phone component and, same as the text component, be sure to title the question and rename the variable.
Since the user is entering information into an input box, placeholder text can also be used here. Input mask will be on by default, which will automatically format the user’s response as (123)456-7890 . This setting can be turned off.
#### Email
Now, add an email.
“Warn about common domain typos” is a setting that will be on by default, and will provide a warning for users if it detects an error in the email domain (e.g. gnail.com vs gmail.com).
{% hint style="info" %}
It is generally good practice to give context as to why contact information is being collected, and what you plan to do with this information. A [tooltip](https://docs.formsort.com/building-flows/adding-content/adding-content#info-text-and-tooltips) is a great way to add this additional context to a question, without adding more components to a page. Simply toggle "**Has info text?**" on, and add the text required to inform your users.
{% endhint %}
### Capture date of birth
Oftentimes we may need to capture a user's date of birth - either to follow up for a birthday, or to tailor an experience [based on the user's age](https://docs.formsort.com/building-flows/schemas/calculated-answers#get-age-from-dob) using a [calculated variable](https://docs.formsort.com/building-flows/schemas/calculated-answers). The [date component](https://docs.formsort.com/building-flows/content-types/date) is the tool of choice here, which can be used for capturing more than just dates of births!
It's up to you where in the flow you'd want to put this question: you can add it to the list of demographic questions on the first step, or - if you'd like the flow to feel more conversational - you can add it to it's own step.
There are a number of options to be toggled with this component, and the list may be worth experimenting with if a date component is going to be used for any other reason. For the purposes of capturing someone's date of birth, it is suggested to at least toggle on "**Only allow dates in the past?**".
### Capture address
Since we've already captured some of the basic contact information for our responder, we might want to capture their address. The [address component](https://docs.formsort.com/building-flows/content-types/address) can be used for this, and will automatically provide the fields required for a complete address.
First, we’ll probably want to create a new step for this, since the address component may take up some real estate if "**Use single field?**" is not enabled. It also helps the user *feel* the progression in the flow, and helps to break up the sense of monotony that comes with filling out a long list.
There are several options for an address component, like formatting for [International addresses](https://docs.formsort.com/building-flows/content-types/address), or [Validating US addresses](https://docs.formsort.com/building-flows/content-types/address) using a USPS integration. It is worth reviewing the detailed [address docs page](https://docs.formsort.com/building-flows/content-types/address) to get a better understanding of what you can do here.
# Add informational content
Add text, photos, and videos to your flow.
Not all of the content you add to your flow needs to be questions you are asking the responder! You also may want to add text or pictures to your flow that are **purely for informational purposes**. Sometimes this is to educate the responder about what you offer, or to provide more information about why they are disqualified from your service.
See the types of informational content you can choose from when you click "**Add Question**" and scroll below "**Content**".
## Common types of informational content:
### Add text and pictures to your steps
You can add add text and pictures before, between, or after the questions you are asking.
### Welcome page
### **Educational steps**
Share facts or statistics that are relevant to your product or service to encourage the responder to continue the flow.
### Transition steps
Tell a responder in the middle of the flow what's about to happen next.
# Template your variables
Refer back to answers already given in your flow.
Sometimes you want to refer back to answers already collected in your flow and display those answers to a responder. A common use case of this is calling the responder by their first name, or reminding them of a choice they had selected in a previous question. This is called **templating variables**.
{% embed url="" %}
### **How to do it in the Studio**
* In this flow, I asked a **Text question** to ask the pet’s name, and I named the variable `pets_name`
* In my next two steps, I insert the answer variable `pets_name` from that question in double brackets.
You can always see a list of the variables you have available to you in the side bar under variables:
### How it looks to a responder
### Other resources
If you need to reformat the variables you collected, please refer to [Templating formatting functions.](/variable-templating#template-formatting-functions)
Use templated variables in [redirect URLs](/variable-templating#redirect-urls) and [image URLs](/variable-templating#inserting-answer-values-into-content).
# Add conditional logic
As a responder is going through your flow, you’ll likely learn information about them that will prompt you to show them a different experience. You can take responders through different paths of your flow by applying **conditional logic** at the question level, the step level, or the group level.
{% embed url="" %}
### How to do it
In Formsort, you add conditional logic to the question, step, or group that you want to be displayed to the responder who matches that criteria.
Take this design below. I want cat and dog owners to be shown the green step because they are eligible for my services, but other pet types to be shown a disqualification screen.
***
### **Disqualifying Responders (Example)**
Sometimes, you’ll need to determine whether a responder meets your eligibility requirements—and if they don’t, stop them from proceeding through the rest of your flow. This is a common use case for conditional logic, and it allows you to tailor the experience for ineligible responders while collecting only the information you need.
Before building your disqualification logic, consider the following:
* What are the qualification criteria for my service?
* What information do I still want to collect from disqualified responders who may qualify in the future?
* Where should disqualified responders go next—should they be redirected, emailed, or shown a custom message?
#### How to Disqualify Responders
1. **Determine your qualification criteria.**\
Common criteria include age, location, or specific answers to questions like medical history or income range.
2. **Collect the right data.**\
Add the necessary steps and questions to your flow so you can evaluate each responder. For example:
* Use a **select question** with a **choice library** to list all 50 U.S. states.
* Ask a **yes/no question** to confirm a qualifying condition (e.g. “Are you 18 or older?”).
* For more accuracy, calculate age from the responder’s date of birth using a calculated variable. Learn how to calculate age from date of birth →
3. **Add a disqualification step or group.**\
Create the step (or group of steps) that disqualified responders will see. This might be a simple message ending the flow, or a series of steps to collect follow-up info or offer alternative next steps.
4. **Apply conditional logic.**\
Add logic to the disqualification step or group so it only shows for responders who **do not meet your criteria**. Place this logic at the point in the flow where disqualification should occur.
> Tip: If you're redirecting responders at this point, make sure they won’t hit later steps unintentionally.
5. **Configure the end of the flow.**\
Once responders reach the disqualification step, consider what you want to happen next:
* Redirect to a help center or FAQ
* Show a friendly message explaining why they aren’t eligible
* Offer an email sign-up to notify them when they become eligible\
Learn more about finalizing flows →
***
#### Advanced Methods for Disqualification
If your eligibility logic is complex or subject to change, you can streamline it with more advanced tools:
* **Use a** [**calculated variable**](/response-data-collection-and-management/variable-schema/calculated-answers)\
Write a function that determines eligibility in one place, referencing multiple values (e.g. check if the responder’s state is in a list of eligible states).
* **Call your backend with an** [**API variable**](/response-data-collection-and-management/variable-schema/api-answers)\
Send responder data to your server and receive a response indicating whether the user is eligible. This allows you to centralize and update logic outside of the Formsort editor.
# Using conditional logic with Calculated and API variables
Conditionally render questions with advanced calculations
There are plenty of reasons to conditionally render questions in your flow - that is, either present or hide questions because of specific conditions. Some factors may be based on the information your users provide in their answers, like rendering certain questions based on age, or it could be based on factors external to that, like a marketing team hiding an offer that is out of season.
Fortunately, the synergy between Formsort’s conditional logic and API and Calculated variables allows us to automate when questions should be available to the users filling out our forms. But, like anything, this takes a little bit of configuring.
## Using calculated variables to hide questions
The power of calculated variables lies in the flexibility they provide by using Javascript functions (in Typescript format). This requires a little bit of JS/TypeScript familiarity, but it’s a powerful tool!
Below, we’ll go over a couple examples of using Calculated Variables for creating logic.
### Ex 1:
In this example function, we’ll return a Boolean true/false value based on whether or not the user in inside or outside the hours of operation, which are 9am - 5pm, M-F. This will require no direct input from the user, but instead will draw the local time from their browser.
In the variant we’re going to create this logic in, let’s head to our **Calculated Inline** tab under **Variables**, and then into the Calculated variable editor.
Add the calculated variable
The Calculated variable editor
Let’s give the variable a name - we’ll call this one `dayparting_offers`, change the Variable Type to `Boolean` so Formsort knows to expect a T/F return, and drop the code into the **Getter Function Body**.
Setting up the variable
{% hint style="info" %}
You can check the function using the “Test API variable” section at the bottom of the editor.
{% endhint %}
Here is a copy of the code we’re using:
function myFunction(): boolean { // readonly line
var now = new Date();
var hours_in_GMT = now.getUTCHours();
var days_in_GMT = now.getDay();
var days_in_desired_timezone = days_in_GMT;
//time difference to GMT
//In this case EST is 5 hours behind GMT
var time_difference_to_desired_timezone = -5;
var hours_in_desired_timezone = hours_in_GMT + time_difference_to_desired_timezone;
//if its past midnight in GMT, make sure to adjust
if (hours_in_desired_timezone < 0 ) { days_in_desired_timezone = (((days_in_desired_timezone - 1) +7) % 7);
hours_in_desired_timezone = hours_in_desired_timezone + 24;
}
//set the parameters for open hours using military time where Sunday is 0
var start_time;
var close_time;
if ([1,2,3,4,5].indexOf(days_in_desired_timezone) > -1) {
start_time = 9;
close_time = 17;
}
else {
start_time = 0;
close_time = 0;
}
if (hours_in_desired_timezone < close_time && hours_in_desired_timezone >= start_time) {
return true;
}
else {
return false;
}
}
Now, lets use this variable to create logic on steps we only want available inside the hours of operation.
* In **Content**, head to the step we’re putting the logic on. Here, it is going to be Step 1.
* Click **Logic** → **Show conditionally** → **Add condition…**
Navigate to Step logic menu
* Select our variable `dayparting_offers` in the variable logic editor, and set it equal to **true**. **Save condition**.
Adding the step logic
* You can repeat this on Step 2 as well, but instead set the variable value to **false**.
* You should see that the step logic will be visible on the steps we’ve set it on.
Now, depending on your local time, you will see either Step 1 or Step 2. Try it out in Live Preview!
### Ex 2:
This next example will hide a step based on our user’s age. This will require us to take the user’s `date of birth` response as an input to our calculated variable, run a function that will return an `age`, and set our step logic based on that age.
{% hint style="info" %}
Setting logic against a [date object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date) can be tricky and unreliable. If you opt to filter users based on their age, it’s recommended to use this method, which sets logic against a [number](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number).
{% endhint %}
First, let’s create a question to capture the user’s dob.
* At the desired step, choose “Add question” and select the [Date](https://docs.formsort.com/building-flows/content-types/date) component. Set the **Variable** name (we’re using `dob`).
Naming our variable
Now, we can take this input and dynamically create an age, depending on the user’s answer.
Head to **Calculated Inline** in our **Variables** section, and “Add calculated variable”.
* Give the function a name (we’ll call this one `age`) and set the **Variable Type** to **number** so Formsort knows to expect an integer.
* Toggle “**Uses other variables**”, and select `dob` from your variable list.
* Drop in the function
Set the dependent variable
{% hint style="info" %}
You can check the function using the “Test API variable” section at the bottom of the editor.
{% endhint %}
Here is a copy of the code we’re using:
{% code overflow="wrap" %}
```javascript
// dob is taken from our "Uses other variables" input
function myFunction(patient_dob: string): number { // readonly line
const ageDifMs = Date.now() - (new Date(dob)).getTime();
const ageDate = new Date(ageDifMs);
return Math.abs(ageDate.getUTCFullYear() - 1970);
}
```
{% endcode %}
Now, lets use this variable to create logic on steps for users *at or above a certain age*.
* In **Content**, head to the step we’re putting the logic on. Here, it is going to be Step 3.
* Click **Logic** → **Show conditionally** → **Add condition…**
Adding Step logic
* Select our variable `age` in the variable logic editor, and set it to **greater than 17**. **Save condition**.
Creating the Step logic
The inline Step logic indicator
Now, if our user’s `dob` puts them at an age that is younger than 16, they will skip Step 3 and move right on to Step 4. Try it out in Live Preview!
For more information on Calculated Variables and the options in our Calculated Variable editor, see our [docs](https://docs.formsort.com/building-flows/schemas/calculated-answers)!
## Using API variables to hide questions
[API variables](https://docs.formsort.com/building-flows/schemas/api-answers) make it possible to fetch data from a server that returns JSON responses. This server can be one you own, or it can be a 3rd party server that has information you need. As long as it returns a JSON response, and *you* can provide authentication into it (if necessary), we can ping it.
Once the API call returns the information we need, we can use the response to create logic on the steps we want to conditionally render.
### Example
In the example below, we will [**template**](https://docs.formsort.com/building-flows/adding-content/using-answers-in-templates?q=templat) a user’s response into our call to the [World Time API](http://worldtimeapi.org/) to determine their timezone, and thus determine which questions to hide.
First, let’s set up a question to find out where the user lives.
* Head into your variant and create the question. We’re using a [select question](https://docs.formsort.com/building-flows/content-types/select) here to provide a list of possible responses for our user.
Creating our Select question
* Give the variable name something recognizable. This question will have the variable name `user_city`.
Naming the variable
Now, let’s set up the API variable to return the time zone, based on the user’s answer.
* Head into **Variables** → **API lookups** and then “**+Add api variable**”.
Adding the API variable
* Add a variable name, and set the [**variable type**](https://docs.formsort.com/building-flows/schemas/api-answers#variable-type). Variable type is the expected data type we’ll be receiving from the API response (i.e. string, number, boolean, object, array).
* If we call this particular API with the `area` and `region` specified in the URL path, we will get an object return with the timezone information about the region.
Example call with area: America and region: Denver
* Now that we know what kind of return to expect, we can add the variable value of `user_city` to our URL path, to make the API call dynamic.
* Click “**Variables…**”, select `user_city`, and paste the variable into the URL path.
Open the available variables menu
Grab the variable we want
Paste the variable into URL path
* Now, we can double check the API call using the **Test API variable** section to make sure we’ll get the response we want. Select a value from the **USER\_CITY** dropdown, then hit “Send test request”.
* Looks like we have a matching result! All we want from this call is the value for the `abbreviation` field in our return. Let’s use the **JSON Accessor** in **Result processing**.
Error?
* We returned an error! The API editor is still expecting an object, but the JSON accessor is returning string value. Let’s adjust our expected **variable type** and re-test.
Success! Denver is in MST
We have the question we need to grab our user’s city, and we have confirmed that our API call will work with that information. All that’s left to do is create logic on the questions we want to hide, depending on the user’s time zone.
* Let’s create a Step that will not be available to users in “MST”. On that step, head to **Logic**, toggle **Show conditionally** on, and create the logic required. **Save condition**.
* Now, when a user answers “Denver” to question 1, they will not see question 2, and will instead skip to question 3. Try it out in Live Preview!
This is one simple API variable use case, but there are a lot of different ways the API variable editor can be configured, like using a mapping function to parse API responses, adding a URL fallback in case the API is unavailable, or making the API fetch conditional on some other conditions.
Make sure to see our [API Variable documentation](/response-data-collection-and-management/variable-schema/api-answers), or, if you’re like us, play around with it and see what you can do!
# Add a scheduling option
If your signup flow includes a scheduling element, there are a few different ways you can direct your responders to select a time.
### Method 1: Add a redirect
Redirect out of the flow to a calendar app (like Calendly or Acuity) using a[ Redirect](/redirects-and-endings#redirects).
How to do it:
* When the responder hits a certain step, they can be automatically redirected, or they can click a Next/Submit button to be redirected to a new URL
* You can have conditional redirects — so some responders can go to different URLs depending on specific criteria
* You can add[ query params](/variable-templating#redirect-urls) to the redirect URL so you can pass data to the scheduling tool
* Note that a redirect finalizes the flow, so you’ll have to keep that in mind if you are analyzing flow analytics and/or want them to be redirected back into the flow to finish additional steps. In the case where you want to have the responder continue the flow, you will need to create a different second flow to redirect them into.
Some scheduling applications have their own redirects after an appointment or meeting is scheduled!
This makes it possible to redirect the responder back into a new Formsort flow after they've booked something. You can use [external variables](/response-data-collection-and-management/variable-schema/external-answers) to bring in any information about the appointment the responder booked.
{% hint style="info" %}
Formsort does not currently support redirecting users back in to the same flow that the user was redirected out of. This is because redirecting a user out of a flow will finalize the flow at the step the user is redirected, and users cannot return to finalized flows.
For this reason, we suggest using redirects when it makes sense to finalize one flow, and then redirect the user back into a **new** flow if they need to continue.
{% endhint %}
### Method 2: Use a custom question
You can also choose to embed a scheduling app directly into your flow as a[ custom question](/adding-questions-and-content/question-reference/iframe-question). A custom question is hosted by you in an iFrame.
The benefits to this is that you can keep the responder journey contained to the flow, so it can feel like a more cohesive experience.
How to do it:
* Add a[ custom question](/adding-questions-and-content/question-reference/iframe-question) to render a calendar app in an iFrame
* You can create multiple conditional custom questions, or every responder can see the same one.
* Use the editor on the right sidebar to customize the question further.
* Use the [custom question API](/adding-questions-and-content/question-reference/iframe-question) to collect answers
{% hint style="warning" %}
Note that you'll need to use the[ custom question API](/adding-questions-and-content/question-reference/iframe-question) in order to allow a responder to proceed through the flow and collect their answers. Otherwise, Formsort has no way of knowing that the question has been completed.
If this doesn't work for your use case, mark the question as **optional**.
{% endhint %}
{% hint style="info" %}
Looking to embed Calendly via a custom question? Check out [this example](https://github.com/formsort/custom-question-examples).
{% endhint %}
### Method 3: Return answers via API choices on a select question
If you have an API of “available times”, you can dynamically generate those choices in a select question.
1. Add a[ Select](/adding-questions-and-content/question-reference/select) question
2. Navigate to Choices > Load choices dynamically
3. Choose External API that displays the choices (see more about [providing choices via API](/adding-questions-and-content/question-reference/select#dynamic-choice-loading))
# End the flow
Manage how your responders exit your flow.
Responders might end the flow at different points, depending on the experience you have built for them.
There are a few different ways to end the flow for a responder. Remember that you can choose the behavior for responders that partially complete a flow and then return to it in [returning responder behavior.](/form-behavior-settings/variant-settings/returning-responder-behavior)
### If the responder exits the flow early:
If you have conditional logic, you may want to end their flow earlier. A common use case for this is when the responder has given you information that disqualifies them for your product or service.
#### Here's how to set up a disqualifying step:
1. Create a step that tells the responder that they are not eligible.
2. Create **conditional logic** on the step so that only the disqualified responders see it. Make this step **finalizing** for them.
{% hint style="info" %}
**Pro tip**: you can use [markdown](/styling/customizing-appearance/typography#markdown-styling-support) to add a link to your homepage so users have a place to go after finalizing the form!
{% endhint %}
### If the responder completes the entire flow:
* Show them a thank you screen that indicates that the flow is completed. You can configure your confirmation text in **Settings > Strings > Confirmation Text**
{% hint style="info" %}
The Settings tab also lets you set behavior for returning responders so you have more control of what happens when responders return back to a partially completed or completed flow.
Learn more about returning responder behavior [here](/form-behavior-settings/variant-settings/returning-responder-behavior).
{% endhint %}
* Show them a finalizing step
* Redirect them to a different page at the end, such as your FAQ or a testimonials page. See more about redirects [here](https://docs.formsort.com/building-flows/redirects).
{% hint style="success" %}
To make the redirect experience less abrupt, you can also add in a gif or animation to the last step the responder sees. Check out some [examples of loading images](https://fineflows.com/elements/loading-indicator).
{% endhint %}
# Review your variable schema
Manage the data you are collecting from responders and sending to your integrations.
As responders go through your flow, you will build up a **schema** of answer variables from them — either through answers they have given directly, or other methods. You can view and edit all of your variables in the Schema tab.
### Types of variables:
* [Variables from questions:](/response-data-collection-and-management/variable-schema/variables-from-questions) Variables you collect from the responder directly when they answer a question. Examples: `first_name`, `dog_breed, pet_type`
* [Externally provided](/response-data-collection-and-management/variable-schema/external-answers): Variables you can pass through the URL of the flow. This can be helpful to add in information about the responder that they might not be able to answer directly, like their unique ID, or Common examples: `UTM source`, \`
* [API lookups:](/response-data-collection-and-management/variable-schema/api-answers) you can fetch a new answer from a server that returns JSON responses. This lookup can even use other variables collected with the flow as inputs or parameters. Examples are calling your own healthcare provider database, finding the nearest store location, or looking up current pricing.
* [Calculated inline](/response-data-collection-and-management/variable-schema/calculated-answers): Allow you to define new answers based on other answers present within the flow, by writing simple javascript functions that are evaluated within Formsort. A common example is calculating age from a responder’s inputted date of birth (see [here](/response-data-collection-and-management/variable-schema/calculated-answers#get-age-from-dob))
* [System library](/response-data-collection-and-management/variable-schema/system-library-answers): Variables you can collect about the responder's experience with your flow. Examples include: `current_step_id, is_mobile, is_returning_responder`.
# Set up integrations
Send your flow data to analytics or data storage tools.
From the **Integrations** tab, you can configure where you were will send data, the shape of submission data, and the frequency with which data is sent.
{% hint style="info" %}
For any changes in the Integrations tab to be reflected in your flow/variant, you must republish after changes are made.
{% endhint %}
## Sending analytics events
[Amplitude](/integrations/integration-reference/amplitude), [Google Analytics](/integrations/integration-reference/google-analytics), [Google Tag Manager](/integrations/integration-reference/google-tag-manager), and [Segment](/integrations/integration-reference/segment) can be configured to receive [analytics events](/integrations/getting-data-out/analytics).
The analytics destinations can also receive answer payloads. You must opt-in to this when configuring them in the integrations editor by toggling "Send answers" on.
## Sending answers
[BigQuery](/integrations/integration-reference/bigquery), [Redshift](/integrations/integration-reference/redshift), and [Webhooks](/integrations/integration-reference/webhooks) can be configured to receive answer payloads. At the [submission frequency](/integrations/getting-data-out/submission-frequencies) that you define, the entire answer payload will be sent to the integration.
Due to the distributed nature of our system, there are a couple of factors you should consider when setting up [BigQuery](/integrations/integration-reference/bigquery), [Redshift](/integrations/integration-reference/redshift), and [Webhooks](/integrations/integration-reference/webhooks) integrations:\
\
1\. Ordering of answer submissions is not guaranteed. This can be particularly noticeable when you use a submission frequency of “Every Step”. For example, if steps are completed in quick succession, ordering of your submissions may not exactly match completion order. \
\
2\. While we guarantee at-least-once delivery of all answer submissions, regardless of frequency, **we cannot guarantee only-once delivery**. All integration targets should be designed with idempotency in mind. Receiving a duplicate answer submission should not adversely affect processing.
{% hint style="info" %}
**When does passed in data get sent?**
Answers passed in via URL parameter or POST body will be included in all answer payloads regardless of the step order.
{% endhint %}
{% hint style="info" %}
**Sending data to a Google Spreadsheet**
Spreadsheets are not databases, and have a slew of problems when you treat them as such, however, we recognize their usefulness, particularly when getting a new project up to speed.
Formsort has a first-party integration with Google Sheets. See more in our [Google Sheets documentation.](/integrations/integration-reference/google-sheets)
{% endhint %}
## Viewing and testing webhook payloads
When you set up a webhook, you can view a sample answer payload in the Webhooks tab once you select a submission frequency. More about submission frequencies [here](/integrations/getting-data-out/submission-frequencies).
{% embed url="" %}
## Receiving uploads
[Amazon S3](/integrations/integration-reference/s3) and [Google Cloud Storage](/integrations/integration-reference/google-cloud-storage) can be configured to receive uploads, such as from [file upload](/adding-questions-and-content/question-reference/file-upload), [image upload](/adding-questions-and-content/question-reference/image-upload), or [signature](/adding-questions-and-content/question-reference/signature) questions. The answer itself will contain the S3/GCS URL of the uploaded asset.
# How data works in Formsort
Formsort is designed to help you **collect responder data** and reliably **send it to your own databases, tools, and workflows**. While we offer secure, built-in response storage, our goal is always to give you full control over your data.
### We store responses by default
As soon as someone begins interacting with your form, their answers—including partial ones—are automatically saved and visible in the **Responses** tab of the Formsort studio. These responses remain accessible unless archived.
* All answers are **encrypted** and **HIPAA-compliant**.
* **Enterprise teams** can opt out of storage entirely, relying solely on external integrations.
### Send answers to your own systems
In addition to storing data, Formsort allows you to **forward responses to third-party destinations** via:
* Our native integration ecosystem
* External API lookups
* Dynamic URL parameters and cookies
This makes it easy to fit Formsort into your broader data ecosystem.
### Incomplete sessions are stored separately
To support session continuity, we also store partial form-fills in a separate, temporary system—so responders can return and finish later.
* These sessions are saved in an **encrypted S3 bucket** and retained for **21 days** from the time of last submission.
* Each time a responder revisits a form and submits new data, the 21-day clock resets.
* This mechanism is separate from your saved responses and can be used even if response storage is disabled.
***
### HIPAA-compliant answer storage
All stored responses are **encrypted and comply with HIPAA standards**. Formsort does not delete responses, but users can manage response access and visibility through archiving.
{% hint style="info" %}
Enterprise users can disable response storage - Formsort will not store your form responses on the platform. Instead, responses are held in a secure, encrypted S3 bucket for 21 days only, after which they are permanently deleted. Use external integrations to manage your long-term data storage.
{% endhint %}
# Responder UUIDs
Identifying individual responders using a unique ID.
A **responder UUID** (Universally Unique Identifier) is a unique value used to identify a user's browser session. This UUID is automatically generated by Formsort when a user loads a form for the first time and is stored in their browser’s `localStorage`.
By default, the UUID persists across visits, allowing Formsort to:
* Recognize returning users,
* Restore saved answers,
* And tie together session-specific data like events and submissions.
### When Is a Responder UUID Generated?
You don’t need to provide a UUID manually. Formsort automatically generates a `responderUuid` during a responder’s first session.
If you’d like to generate a **new UUID** every time someone visits your form (even in the same browser), enable **Start each session as a new responder** in your variant settings.
### Manually Setting a Responder UUID
While auto-generation works for most use cases, you can also provide your own responder UUID. This is useful if:
* You already have a unique identifier for a user (e.g. a user ID or session ID),
* You want to force-load a specific session tied to that identifier.
#### Two ways to set the responder UUID manually:
1. **Via the URL parameter** `responderUuid`**:**
```
https://?responderUuid=123e4567-e89b-12d3-a456-426614174000
```
2. **Via HTML POST body:**
```
```
{% hint style="info" %}
:bulb:You can also use URL parameters to set initial answers in the form—see our full guide for more.
{% endhint %}
#### Important notes:
* `responderUuid` must be a valid UUID string in the format:\
`xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`\
(e.g., `123e4567-e89b-12d3-a456-426614174000`)
* Force-loading a session with `responderUuid` **will not work** if:
* **Start each session as a new responder** is enabled, or
* The user’s previous session has been finalized.
### Making the responder UUID available as an answer
You can make the `responderUuid` available as an **answer variable** in your flow by adding it from the **System Library** into your form schema.
The System Library menu
Once added:
* It can be templated into redirects or API calls, or anywhere templating is allowed.
* You can reference it like any other variable in your flow.
{% hint style="info" %}
Learn more about [variable templating](/variable-templating) for dynamic usage of answer data in your form logic.
{% endhint %}
# Understanding flows
### Key Concepts
Formsort uses a few foundational concepts that work together to help you build, manage, and optimize form flows. Here’s how they connect:
#### Flow
A **flow** is a full form experience, like a signup, onboarding, or lead capture journey. Think of it as the container for everything the user sees and interacts with. Each flow lives in the Studio and serves a distinct purpose.
**Example:**
* `signup-flow`
* `onboarding-flow`
#### Variant
A **variant** is a version of a flow. Every flow begins with a **Main** variant, but you can duplicate and modify variants to test different user experiences.
Variants all aim to achieve the same goal but may include different steps, logic, or copy.
#### Group
**Groups** are optional, but useful for organizing complex flows. A group is a collection of **steps** within a variant, helping you logically separate sections of a form.
{% hint style="info" %}
Groups are not visible to responders—they’re for internal organization only.
{% endhint %}
#### Step
A **step** is a single "page" of your flow. It organizes **questions** into digestible sections, guiding responders through the form experience.
Steps live inside groups (or directly inside a variant if no groups are used).
A step with a question
#### Question
**Questions** are the form fields that collect user input and stores them into **variables** —like name, email, or file uploads. You can drag-and-drop questions to reorder them, move them across steps, or display them side-by-side.
{% hint style="info" %}
Example: collect first name and last name in a single row.
{% endhint %}
#### Variable
A **variable** is a reference to the **responder's** answer for a specific **question** in your form, used to store and retrieve their responses within Formsort and your external systems. In addition to question variables, other types of variables exist, such as those provided externally, calculated inline, or retrieved through API lookups and system libraries — all of which are automatically saved as part of your form responses, and sent to your data integrations.
{% hint style="info" %}
Variables have a wide range of configuration options—check out the section [**Understanding variables**](/adding-questions-and-content#understanding-variables) below to explore them all in detail.
{% endhint %}
#### Responder
A **responder** is your end user—the person going through your flow and submitting answers. All session data and responses are tied to the responder.
#### Conditional logic
Conditional logic allows flows to adapt dynamically to responder inputs, enabling a personalized experience without the need to create multiple flows. It can be applied to control the visibility and behavior of **questions**, **steps**, **groups**, and redirects.
# 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](/core-concepts/versioning-in-formsort-deploying/variant-revisions) of your form.
{% 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**.
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](/core-concepts/versioning-in-formsort-deploying/variant-revisions) will be created
* If you’ve set up [Subscriptions](/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**](/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.
To learn more, see the [Managing Revisions](/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.
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.
# Variant revisions
## Variant Revision UUID
When you [deploy](/core-concepts/versioning-in-formsort-deploying#deploying-your-flow) 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.
### Pinning
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 [**Superseding existing versions**](/core-concepts/versioning-in-formsort-deploying#superceding-past-revisions-of-a-variant).
#### Preventing pinning
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
{% hint style="info" %}
💡 **Pro tip:** Testing a recent change but still seeing an old version? Open the form in an incognito window to make sure you're seeing the latest deployed revision!
{% endhint %}
### Checking Variant Caching
If you’re troubleshooting and want to confirm which variant revision is cached:
1. Open your live flow.
2. Right-click anywhere and select **Inspect** to open your browser's developer tools.
3. Go to the **Network** tab.
4. Look for a fetch request with the name of the variant deployment ID.
5. In that request, you’ll find the `variant_revision_uuid`.
{% hint style="warning" %}
You may need to reload the page after opening the **Network** tab—the fetch call is made **once** when the flow **initially loads**.
{% endhint %}
***
### Force‑Loading a Specific Revision
If you need to test or share an exact revision, append the `variantRevisionUuid` parameter to your form’s URL:
```http
https://your-form-url?variantRevisionUuid=YOUR_UUID_HERE
```
Replace `YOUR_UUID_HERE` with the target revision’s `variant_revision_uuid`.
{% hint style="info" %}
💡 Use this sparingly—hardcoding a revision UUID bypasses the normal publish workflow and can prevent future live updates from taking effect.
{% endhint %}
# Managing revisions
Formsort automatically saves every deployed revision of a variant. From the **History** tab, you can revert to a previous revision to inspect its structure and, if needed, redeploy it to make it live again. You can also view the JSON definition of any revision.
## Viewing & Reverting Revisions
1. **Open the variant** in Studio.
2. Click the **History** tab to see all past deployments—each entry shows the revision UUID, date, and any deployment notes.
3. To revert, find the desired revision, open its 3-button menu, and select **Revert**. Confirm the action to roll back the live flow to that revision.
4. **Optional:** Deploy your form for the reverted changes to go Live.
{% hint style="warning" %}
You can only revert to revisions that have been deployed—drafts aren’t available for reversion.
{% endhint %}
### Viewing JSON definition
You can also use the 3-button menu to access the JSON definition of the schema of the revision.
# Building a new flow
Create a new flow by starting from a prebuilt template or from scratch. You’ll choose a theme, configure flow details like name and URL slug, and then launch your form with a click.
In your studio, click **+ New Flow** to open a dialog box with two options:
* **Start from a template**
* **Start from blank**
The sections below walk through each option.
You can either pick a template or start from scratch
### Templates
#### Choosing a template
Templates give you a head start by including prebuilt content and a default theme tailored for a specific use case—such as Patient Health Questionnaires, Net Promoter Score surveys, or Job Application forms.
If a template includes questions with calculated answers, the necessary calculated variables will be included automatically. For example, the PHQ‑9 template includes a scoring variable based on responder answers.
Templates are fully editable. You can modify or delete any content after creating your flow.
To get started, find the template you want and click on it. You’ll be taken to **Flow Details** to finalize setup before creating your flow.
### Starting blank
If you choose to start blank, you’ll be taken directly to the **Pick a Theme** step.
Here, you can:
* Choose a theme
* Edit flow details like the name, URL slug, and description
See **Flow Details** below for more on these settings.\
Once you're happy with your selections, click **Create a new flow!**
***
## Flow Details
Flow Details help organize your studio and define how your form is accessed. These include:
* **Flow Name** – The internal name for your flow in your studio
* **URL Slug** – The unique part of your form’s URL
* **Description** (optional) – A short internal note to help differentiate flows
If you’re starting from a template, you’ll also see a live preview of the template. You can interact with it before clicking **Use this template** to create your flow.
### Set a Flow name and URL slug
The **Flow Name** determines how your flow appears in your studio. By default, it’s also used to generate the **URL Slug**, which becomes part of the public form link:
```http
https://{your-domain}/flow/{url-slug}
```
If you open **Advanced Options**, you can:
* Edit the URL slug (it’s pre-filled from the Flow Name)
* Add an optional description
{% hint style="warning" %}
**Note:** The URL slug cannot be changed once the flow is created. Double-check it before proceeding to avoid ending up with a confusing or messy public link.
{% endhint %}
If you need to change the slug after creating the flow, see our [duplicating variants](/flow-variant-management#duplicating-variants) guide to create a new flow with your desired slug.
The Flow Name and Description are only visible to your team within the studio.
# Groups
Groups are helpful organizers for steps.
**Groups** help structure your flow by organizing steps into logical sections. They support conditional logic, custom styling, and dynamic ordering, making it easier to manage and present complex forms.
Groups themselves are not content, but help keep your flow and studio organized by acting as containers for **steps**. They can:
* be [conditionally enabled](/conditions-and-logic), which will either hide or render the steps inside.
* use their own styling that overrides the flow theme.
* be dynamically re-ordered using the [Group Ranking API](/form-behavior-settings/variant-settings/group-ranking-api).
The user moves through the flow starting from the group at the top, down to the last group. This is the default behavior for Formsort.
{% hint style="info" %}
If you'd like to allow your user to jump around the flow, see our [Navigation Sidebar](/styling/customizing-appearance/content-area-and-form-layout#navigation-sidebar).
{% endhint %}
## Adding steps to a group
Click "Edit groups" to open the Group menu
Press the caret to close the Group menu
To add a group, click **Edit groups** when hovering the left-side groups editor, or click the arrow at the top right.
In the expanded group editor, you can add groups and then create steps within them.
If you want to move existing steps into a group, you can drag the step into the groups while the group editor is expanded. Alternatively, you can use [cut and paste](/creating-flows/building-a-new-flow/copy-paste-of-form-content) steps to re-organize content between groups.
If you do not create groups, all steps appear within a *default* group.
***
## Group settings
#### Group Label
You can add a label to easier identify the function of a Group, e.g. naming a Group "Introduction" if it houses the content/questions related to introducing a user to the form. Group labels are not shown to users, unless you choose to show them within the [progress bar](/styling/customizing-appearance/progress-bars#counting-groups-or-steps).
#### Group ID
Used to create a stable definition/ID of the group when using the [Group Ranking API](/form-behavior-settings/variant-settings/group-ranking-api). See the linked documentation for more information.
***
## Group logic
Groups can be made [conditional](/conditions-and-logic), which will show or hide all the steps within a group all at once.
Rendering a group based on a external variable being passed in at flow load.
## Style
### Styling groups
[Group style overrides](/css-and-advanced-styling#group-style-overrides) can be used to alter any part of the general Theme set within a group.
Group style override menu
These are particularly handy if you have distinct sections of a flow which might want to adopt a slightly different look and feel.
For example, you might have an *Introduction* group that contains some lightweight questions and content perhaps a more colorful and spacious design. You can follow that with a *Data collection* group that has a denser layout to facilitate answering many questions all together
# Steps
Steps are containers for questions and content.
A step is viewed as a single page within a flow, which may contain one or many questions. Steps themselves act as containers and do not collect information directly.
In the Studio, steps can be easily reordered by dragging and dropping them. Each step is indexed in the top-left corner (e.g., "Step 1") for easy reference. When a user navigates through a live flow, the step index is reflected in the URL, allowing browser navigation between steps. For example, the URL `https://formsortstuff.formsort.app/flow/all-components/variant/main#1` indicates that the user is at step index 1.
Each step has its own settings, logic, styling, and redirect behavior.
{% hint style="info" %}
:bulb:For more information about redirects, see the **Redirects** section.
{% endhint %}
***
### Settings
#### Step ID
Assigning a Step ID creates a stable reference for a step even as steps are reordered or renamed. This is especially helpful for analytics, where tracking step performance across versions is important, and for applying custom CSS. Step IDs must be unique when set but are not required—if omitted, the step index will be used instead in analytics payloads.
{% hint style="info" %}
To include Step ID in the form submission payload, add **current step id** to your [library variable](/response-data-collection-and-management/variable-schema/system-library-answers#overview-of-library-answers) schema.
{% endhint %}
#### Auto-advance after ms
If enabled, the step will automatically advance after the specified timeout. This is useful for creating interstitial screens that do not require user input. Auto-advancement will only occur if:
* All required questions are answered,
* All questions are optional, or
* No questions are present (e.g., only Statements or Images).
#### Is savepoint
If your answer submission frequency is set to *On savepoint* or *When the flow is finalized or abandoned*, enabling *Is savepoint* ensures that responder answers are submitted to your integrations when this step is **completed**.
***
### Logic
Steps can be conditionally rendered based on previous answers and can control flow navigation.
Rendering the first step based on an external variable value
#### Show conditionally
Use conditional logic to show or hide steps based on answers provided earlier in the flow. Logic cannot be based on answers that come later.
{% hint style="info" %}
:bulb:See Conditions and Logic for more details.
{% endhint %}
#### Disable back navigation
When enabled, responders cannot navigate backward past the step. The "Previous" button will be hidden, and browser back navigation will be disabled. This is useful for steps where changing earlier responses would not make sense (e.g., after a payment has been completed).
#### Disable forward navigation
When enabled, responders cannot move forward from the step. ***This finalizes the form session when the step loads***, preventing further answer collection. Content like Images or Statements can still be displayed.
#### Finalizing steps
If *Is finalizing?* is enabled:
* The `FlowFinalized` event will be emitted to analytics integrations upon loading.
* An answer payload with `finalized: true` will be delivered to your answer integrations.
* Responders will not be able to advance beyond this step, and redirects cannot be configured for it.
{% hint style="warning" %}
Since the flow is finalized when the step loads, you cannot collect answers from a finalizing step.
{% endhint %}
***
### Common Step Patterns: Collecting a Waitlist Email from Disqualified Responders
Let’s put some of the Step settings and logic into action with a common pattern: collecting an email address from users who are disqualified from continuing. This approach helps you build waitlists, collect feedback, or stay in touch with users who don't complete the primary flow.
To implement this pattern:
1. **Determine disqualification:**\
Use a [calculated answer](/response-data-collection-and-management/variable-schema/calculated-answers) or [API answer](/response-data-collection-and-management/variable-schema/api-answers) to evaluate whether a responder should be disqualified. Name it something semantic, such as `is_disqualified`.
2. **Add a waitlist step:**\
Create a step containing the questions you want to ask disqualified users (for example, an email input saved as `waitlist_email`). Set a show condition on the step: `is_disqualified Equals true`.\
This ensures only disqualified users see this step and can submit their contact information.
To prevent users from returning to earlier questions and altering their answers to re-qualify, enable **Disable back navigation** on this step.
3. **Finalize the experience:**\
After collecting the waitlist information, you can either:
* **Option 1: Show a thank-you step:**\
Add a final step that displays informational content (e.g., a thank-you message).
* Set **Disable forward navigation** so the responder cannot proceed further.
* Set the step to **show conditionally** if `waitlist_email Is defined`, ensuring it only appears if an email is provided.
* Optionally, **enable Finalizing** to trigger a `FlowFinalized` event for your analytics and integrations.
* **Option 2: Redirect the user:**\
Instead of showing a final step, you can configure a **redirect** to send the responder to an external page, such as your homepage or a custom thank-you page.\
This can be done by setting a redirect conditionally after the waitlist step is completed.
# Copy-pasting form content
Cut, copy, and paste work whenever your have a group, step, question, or variable selected: within flows, or even between flows.
### Copying and pasting items
When an item is focused, there is a sub-menu that will allow you to copy/cut an item. Alternatively, you can right-click the item.
This is available on groups, steps, and questions.
Once an item is copied, you can paste by right clicking the target area and:
When pasting content that depends on answers from other parts of a flow, you’ll need to guide the Formsort studio on how to handle those dependencies. This process is called **mapping input variables**.
### Mapping input variables
If you paste a flow slice that contains variables—such as [templated labels](/variable-templating) or questions that rely on conditional logic—you'll be prompted to map those variables to existing answers in your flow.
Flow slices that contain only static content (like informational text or images) can be pasted without any additional configuration.
When mapping input variables, you’ll have a few options:
### Create new answer
Adds a new question to the beginning of the pasted slice to collect the required input from the responder.
### Map to existing answer
If your flow already collects an answer of the correct type, you can map the variable to that existing answer—no new question needed.
This process is great for creating duplicate instances of a question.
# Adding questions and content
### Understanding Questions
To capture **variables** in your flow, you’ll use questions—building blocks designed to collect input from responders. Each question stores the responder’s input as a variable, which can then be referenced throughout your flow for logic, personalization, and integrations. Formsort provides a variety of question types and configuration options to support different data formats, UI preferences, and conditional logic needs. The sections below cover how variables are created through questions and how they behave across your flow.
See the question-variable relationship here:
{% hint style="info" %}
Head to the [Questions](/adding-questions-and-content/question-reference) sub-section for more information.
{% endhint %}
***
### Variables (Answers)
Variables in Formsort allow you to use and classify answers and other data once it has been collected. Every **question** in your form is associated with a **variable** where the responder's answers are stored. These variables are referred to as **variables from questions**.
{% hint style="info" %}
:bulb: Additionally, the following types of variables return values that are also stored in variables, though their resolution mechanism differs:
* **Externally provided**
* **API lookups**
* **Calculated inline**
* **System library**
{% endhint %}
{% hint style="info" %}
See our [Schema](/response-data-collection-and-management/variable-schema) section for more information about variables.
{% endhint %}
***
### Understanding Content
In contrast to **questions**, **content** components are used purely for displaying information—they don’t capture or store any data from the responder. These read-only elements help you explain concepts, break up long pages, embed media, and add supporting context to your flow. From simple statements to rich video embeds, content blocks give you the flexibility to design a form that communicates clearly and guides responders effectively.
{% hint style="info" %}
See our [Content](/adding-questions-and-content/content-reference) sub-section for more information.
{% endhint %}
# Questions
Collect answers.
Questions are used to collect specific information from responders within a step and store their answers in variables. Formsort provides a wide range of question components to accommodate different needs—everything from single or multiple-choice options to specialized fields for capturing addresses and more.
These question components can be easily reordered by dragging and dropping them within a step, or even between different steps and groups. Just like steps and groups, questions can also be conditionally rendered based on responder input.
Check out the sub-sections below to explore the different types of questions available and determine which is best suited for your flow’s objectives.
{% hint style="info" %}
Need something more custom? You can embed your own questions using an **iframe** question.
{% endhint %}
***
### General Settings
While some settings are specific to individual question types, the following options are available for all questions:
#### Question label
A text field used to prompt the responder. This label can be edited directly on the question component or via the settings menu.
#### Variable
The name assigned to the answer, as it will appear in your answer payload.
\
By default, this mirrors the Question Label, but you can edit it independently.
\
Example answer format:
```json
answers: {
variable_name: variable_value
}
```
#### Readable description
An internal-only field to help your team understand the purpose of the question.\
This is not shown to responders but can be included in the metadata of answer payloads if enabled in your integration settings.
Example payload snippet:
#### Data classification
Tags the question as collecting personally identifiable information (PII) or another sensitive data type.
#### Question ID
Assign an HTML `id` attribute to the question.\
Useful for targeting with custom CSS.
#### Has info Text?
Provide additional context without cluttering the UI. Enable **Has info text?** to display a tooltip or modal alongside the question.\
You can choose between text links or an icon-based trigger.
{% hint style="warning" %}
Info text is not supported for Select Button components.
{% endhint %}
#### Allow Multiple Answers
Enable this option to let responders submit more than one answer to a question.
Supported question types:
* Date
* Email
* Number
* Phone
* Text
* Select
When enabled, answers are stored as an array:
```
{
"pets": ["cat", "dog", "bird"],
}
```
A **+ Add** button will appear after the first input, allowing responders to enter additional values.
# Select
Allows picking between a few choices.
**Select questions** are the easiest way to collect structured data from responders. Unlike text input fields, responders choose from pre-defined options, reducing friction and error. Common use cases include:
* Single- or multiple-choice questions
* Dropdown selections (e.g., U.S. states)
* Image or video-based pickers
***
### Core Settings
#### Allow multiple selection
Enable this setting to let responders choose more than one answer.
#### Autoadvance if possible
When enabled (default), the flow will automatically advance after the responder selects a choice—**but only if all other questions on the step are already answered**.
{% hint style="info" %}
Autoadvance is disabled when multiple selection is allowed.
{% endhint %}
***
### Customizing choices
#### How to add choices
You can populate choices via:
* **Manual entry** in the **Choices** tab
* **Bulk add** from the **Choice library**
* **Dynamically** via external API lookup or local calculation (see below)
#### Randomize choice order
To reduce bias, enable this setting to shuffle the display order each time the step loads.
{% hint style="info" %}
**Pin to position**
When randomization is on, you can **pin** specific choices (e.g., “Other”, “None”) to always appear in the same position.
{% endhint %}
#### Choice value type
By default, values are stored as strings. You can also choose `boolean` or `number` types from the **Choice value type** menu.
#### Customizing individual choices
Each choice has a:
* **Label** (shown to responder)
* **Value** (stored in submission)
Optional settings include:
* **Show conditionally:** Show the choice only if a condition is met.
* **Exclusive:** Deselect all others if selected (available only when multiple selection is enabled).
* **Disabled:** Prevent selection.
* **Checked by default:** Pre-select this option when the step loads.
* **Description:** Internal-only helper for admins (can be sent in payloads).
* **Media (image/video):** Attach visuals to choices if **Show images on choices** is enabled.
{% hint style="info" %}
You can control the appearance of image/video choices in Theme → Buttons → Select → Image.
{% endhint %}
***
### Using the Choice Library
Formsort provides pre-built sets (e.g., U.S. states, Likert scales). Find them at the bottom of the **Choices** tab.\
Want to suggest a new one?
{% hint style="warning" %}
Adding from the choice library will replace/overwrite any existing choices.
{% endhint %}
***
### Collecting "Other" responses
To capture custom answers:
1. Add an “Other” option.
2. Add a **Text** question that appears conditionally when “Other” is selected.
***
### Dynamic Choice Loading
Dynamic loading is ideal when choices change frequently or are not known at build time.
#### Required format (choice schema)
Choices must follow this structure:
```json
[
{
"label": "The first choice", // Displayed to the user
"value": "choice_a", // Stored in the answers
"disabled": false, // [Optional]: Whether the choice
// is disabled
"imageUrl": "https://..." // [Optional]: If loading choices
// for a select question with
// images, the URL of the image.
}
]
```
#### How to configure
**1. External API**
* Go to **Choices** → **Load choices dynamically** → **External API** → **Define api source**.
* Set the URL for the API.
* If the API response doesn’t match the required schema, use a **result mapping function** to transform it.
Learn more in **API answers**.
**2. Local calculation**
* Choose **Calculated locally** and use TypeScript to generate choices
* The function must `return` an array of objects
```typescript
function myFunction(): IChoice[] { // readonly line
return [
{
label: string,
value: string
}
]
}
```
#### Caclulate locally
When **calculated locally** is enabled, you will be able to use Typescript to output the answers for responder.
You can write any functions you need, but at a minimum, they must return an array of objects that follow the format below.
Calculated
{% hint style="success" %}
See [this video](https://drive.google.com/file/d/1FyxvRJIGjnFKwPs1TyUl58rhvd2qDAGg/view?usp=sharing) comparing different approaches to specifying choices for a visual walkthrough.
{% endhint %}
***
## Styling Choices
In the **Style** menu, use the **Picker Style** dropdown to choose how choices appear:
* Buttons
* Carousel
* Dropdown
* Native dropdown
* List
* Sliders
{% hint style="info" %}
:bulb: For more style customization details, see [Button Styling](/styling/customizing-appearance/buttons).
{% endhint %}
# Text
Collects text answers
Text questions are used to collect short or long-form free-text input from responders. Common use cases include gathering names, email addresses, or open-ended feedback.
Text question answers are stored as a `string` data type.
***
### Long-Text Input
By default, a text question shows a single-line input. To enable multiline responses:
* Select the question.
* Enable **Multiline?** in the settings panel.
* Specify the **minimum** and **maximum number of lines** for the input box.
To customize the dimensions of the input box further (e.g. to create a longer feedback box):
* Open the **Style** tab.
* Toggle **Override default text input style**.
* Apply your desired styling.
#### Limiting Answer Length
To control the length of a responder’s answer:
* Enable **Max length restriction?**
* Choose a limit by **characters** or **words**.
You can also enable **Show remaining count?** to display the number of characters or words remaining as the responder types.
***
### Formatting Input with Prefixes and Suffixes
To provide additional context and guide responders on the expected input, you can add:
* A **Prefix** (e.g. `$` or `@`)
* A **Suffix** (e.g. `USD` or `.com`)
These can be configured in the **Settings** menu under **Prefix?** and **Suffix?**.
***
### Allowing Multiple Answers
To allow a responder to submit more than one value for a single question:
* Enable **Allow multiple answers** in the settings.
Each new input will be treated as an individual item in an array of string values.
***
### Default Answer
Use the **Default answer** setting to prepopulate the text field with a preset value. This value can still be edited by the responder.
#### Using Other Values as Answers
You can dynamically set the value of a Text question by referencing other variables in your flow:
* Enable **Another answer/variable** in the settings.
* Any other data-type-compatible variables will be available to choose (e.g. from a previous question, a calculated variable, or an API response).
This is useful for personalization or autofill behavior (e.g. pulling a first name from a previous step).
#### Constant
To assign a static value to a Text question that never changes:
* Use the **Constant** setting.
This is helpful for storing a fixed value (e.g. an internal tag or a source code) in the answers payload without requiring responder input.
# Address
Collects an address, including street, state and postal code.
Unlike most answers, a default address answer value is stored as an `object`, since it contains multiple parts.
```
{
"my_address": {
"address_1": "213 Main St",
"address_2": "Apt 17",
"city": "Kansas City",
"state": "MO",
"postal_code": "64116"
}
}
```
{% hint style="info" %}
Need only the town / city? See the [Region](/adding-questions-and-content/question-reference/region) question type.
{% endhint %}
If you would like to access one of the parts of the address in a string [template](/core-concepts/formsort-quickstart-guides/template-your-variables), you may use the `get` template function.
Given the above example, a template like:
```
Great, your postal code is {{my_address | get 'postal_code'}}.
```
Would render:
```
Great, your postal code is 64116
```
### Use Single Field
When this option is enabled, Formsort will provide a single input field for the user address, rather than distinct input fields for street address, city, state, and zip.
Single field address vs default address components
The payload for a single field address is a little different than the default, since the data type is considered `string` instead of an address `object`. This means the address details will come in as one `"raw"` property in the address object.
```
{
"my_address": {
"raw": "213 Main St., Apt 17, Kansas City, MO 64116"
}
}
```
### International addresses
If you enable **International?**, then responders will be allowed to choose the country of their address. The saved address will contain the `country` that was selected.
```
{
"my_international_address": {
"address_1": "Strahovské nádvoří 301",
"city": "Praha",
"postal_code": "118 00"
"country": "Czech Republic"
}
}
```
#### Default
When international addresses are enabled, you can set a default country using Default country.
## Setting Address via URL parameter
If you'd like to pass an address into the flow for your user, here is an example of the syntax required for the address component at the top of this section. Notice each `[field]` corresponds to an object key from the example.
You can set all the address fields, or just the fields you have (or want to use).
#### Default address component syntax:
`https://your-flow-url.com?my_address[address_1]=213+Main+St&my_address[address_2]=Apt+17&my_address[city]=Kansas+City&my_address[state]=MO&my_address[postal_code]=64116`
#### Single-field address component syntax:
Since the Single-Field address string will require commas, you may have to URL encode the address before passing it in as a value for the parameter.
`https://your-flow-url.com?my_address[raw]=123%20Main%20St%2C%20Apt%2017%20Kansas%20City%2C%20MO%2C%2064116`
{% hint style="info" %}
See [URL Parameters](https://docs.formsort.com/handling-data/passing-data-in/url-parameters) for more information on passing answers in to a flow.
{% endhint %}
## Autocomplete using Google Places API
Addresses are sometimes tedious to type, so you can use the [Google Places API](https://developers.google.com/places/web-service/get-api-key) to auto-complete addresses, by providing your API key.
{% hint style="info" %}
If you are restricting referrers and/or embedding your Formsort flow, make sure to add `flow.formsort.com` (which is where your flow will be hosted) to the list of allowed referrers in the Google API console, **in addition** to any custom domains on which you are hosting your flows.
Whitelisting `flow.formsort.app` may be necessary for use of the Places API in the Live Preview as well!
{% endhint %}
When enabled, the address answer will also contain a `raw` field which stores the raw string that was entered by the user.
```
{
"my_address": {
"raw": "213 Main St., Apt 17, Kansas City, MO 64116",
"address_1": "213 Main St",
"address_2": "Apt 17",
"city": "Kansas City",
"state": "MO",
"postal_code": "64116"
}
}
```
## Validating form addresses with USPS
{% hint style="info" %}
This feature is only available for addresses in the United States.
{% endhint %}
Enabling **Validate addresses (US only)?** activates the [USPS Addresses API](https://developers.usps.com/addressesv3), which verifies that entered addresses are valid U.S. mailing addresses. Before using this feature, you must configure the USPS integration.\
Follow the guide [here ](/integrations/integration-reference/usps)to get started.
# Comparison
A comparison table, often used for pricing pages.
This question type is commonly used to compare complex offerings such as plans or packages.
## Adding choices
You can add choices by clicking the **+Choice** button in the settings menu with the questions selected. In order to add more details to your choice, click the down caret to expand the setting menu.
Using the same menu, you also have the option to highlight, disable or [conditionally](/conditions-and-logic) show your choices.
For details on how to customize the comparison cards, you can refer to the documentation [here](/styling/customizing-appearance/comparison).
# Confirmation
An acknowledgement checkbox.
This question type is commonly used for documenting that the responder has read the terms and conditions or is acknowledging the information presented in the page.
The answer to a confirm question is stored as a [boolean](/response-data-collection-and-management/variable-schema#variable-data-types).
## **Changing the confirmation text**
You can personalize the text that shows up next to the checkbox by editing the **Confirmation text** field in the setting menu that appears when the question is selected.
## **Setting the default behavior**
If you enable the **Default to be checked** option in the setting menu, the confirmation box will appear in its checked state when the content is first loaded.
{% hint style="info" %}
In order to style the confirmation box (changing the padding between the text and the box or the color), you can style **Multiple Choice (and not the radio buttons)** boxes [checkmarks](/styling/customizing-appearance/checkmarks) menu.
{% endhint %}
# Date
A date picker.
This question type is commonly used for getting a responder's date of birth or their preference for when an event should take place.
The answer to a date question is stored as [Formsort subtype](/response-data-collection-and-management/variable-schema#subtypes) date and are always formatted as [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601).
## **Limiting answers to a specific timeframe**
You can force the responder to pick dates in the future or in the past by enabling the **Only allow dates in the past?** or **Only allow dates in the future?** options. This way you can ensure that your responder's birthdates are not in the future or they do not accidentally schedule an event in the past.
## **Allowing multiple answers**
Enabling **allow multiple answers** lets the respondent pick more than one date as an answer to a question.
## Date picker styling options
The date picker menu can either be native to the platform the respondent is using (e.g. using Google’s date picker on Chrome) or can inherit from the [dropdown menu styling](/styling/customizing-appearance/dropdown-menu).
In order to change the styling of the date picker, you can go to the style tab with the question selected.
## Setting a date answer with URL parameters
Answers for the date component can be passed in via [URL parameter](/importing-data/url-parameters), with the format as `YYYY-MM-DD`. For example, if you want to pass in the `appointment_date` answer "Apr 25 2023", append `?appointment_date=2023-04-25` to the flow URL.
# Date & time
A date picker with the option of specifying time.
The **Date and Time** component is used when specifying time is important as well as the date. Setting meeting times or otherwise establishing timeframes for availability are common use cases.
The answer to a date question is stored as [Formsort subtype](/response-data-collection-and-management/variable-schema#subtypes) *datetime* and are always formatted as [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601).
## **Limiting answers to a specific timeframe**
You can force the responder to pick dates in the future or in the past by enabling the **Only allow times in the past?** or **Only allow times in the future?** options. This way, you can ensure that responders do not accidentally schedule a meeting for a time in the past, or specify a past event as some time in the future.
Additionally, you can set a range of dates and times by enabling **Min date** and **Max date**, which can help ensure users set meetings during available hours.
## Date picker styling options
The date and time menu is rendered from the native date time input of the responder's browser. Currently, there is no dropdown version.
# Email address
Collects email addresses.
This question type is commonly used for collecting and validating email addresses from responders.
## Data structure
The answer to the email question is stored as [Formsort subtype](/response-data-collection-and-management/variable-schema#subtypes) email .
```
{
"my_email": "hello@formsort.com"
}
```
## **Suggesting spelling corrections**
Beyond validating for email structure itself, when **Warn about common domain typos** is enabled, Formsort suggests potential corrections to non-standard domains.
For example, an answer ending like *gnail.com* would be met with a prompt asking if the responder meant *gmail.com,* and the responder would be prompted to correct it before continuing.
{% hint style="info" %}
Warnings about common domain typos work best when responders are consumers using common email providers. If your responders are using business emails you may want to disable this feature.
{% endhint %}
## **Allowing multiple answers**
Enabling **Allow multiple answers** lets the respondent type more than one email address as an answer to your question.
# File upload
Collects various files from the responder.
This question type is used in cases where the responder needs to upload documents, such as a `pdfs` of contracts, certificates, prescriptions, etc.
If you would like to ask the responder take a picture of an ID card or themselves, you can use the[ image upload](/adding-questions-and-content/question-reference/image-upload) content type. If you would like the responder to sign a document, you can use the [signature ](/adding-questions-and-content/question-reference/signature)content type.
{% hint style="info" %}
If you don't want the responder to be held up by a file upload question, make sure to mark the question as [optional](/conditions-and-logic#optional).
{% endhint %}
### Managing File Storage
By default, Formsort securely stores uploaded files and images with our [data storage service](/saving-and-retrieving-responses) — no setup required.\
If you prefer to manage your own storage, you can optionally configure an **S3** or **GCS** bucket as a custom file destination.
To set up a custom integration, follow our detailed guides for:
* [Amazon S3 setup](/integrations/integration-reference/s3)
* [Google Cloud Storage setup](/integrations/integration-reference/google-cloud-storage)
### Creating a filename pattern
You can opt to define a naming pattern for the files that your responders upload by enabling **Filename pattern** in the question settings.
Here, you can [template](/variable-templating) any relevant variable you would like to be included in the name of the file into the field. For example, if you type `{{first_name}}` into the field, the value of the `first_name` variable will be used as the filename at upload.
Formsort also offers three custom variables for these types of file upload components, built right into the settings of the component itself: `sessionUuid`, `randomUuid`, and `currentTimeUTC`. These variables are also able be templated into the **Filename pattern** field to create dynamic filenames.
* `sessionUuid`: a uuid that is created **once**, when the form is loaded.
* `randomUuid`: a uuid that is **created at and re-run** at each upload instance.
* `currentTimeUTC`: a timestamp that is **created at and re-run** at each upload instance.
You can use several of these variables at once, if required, and one pattern we suggest is `{{currentTimeUTC}}_{{responder_uuid}}`. This ensures uniqueness via the timestamp, while still tying the file to a particular user via the `responder_uuid` System Library variable.
{% hint style="info" %}
Visit the [System Library variables](/response-data-collection-and-management/variable-schema/system-library-answers) section for details on built-in variables that provide information about the responder's environment and context.
{% endhint %}
Note that these extensions will be added automatically. You should also set a fallback naming convention in case the variable is not defined by typing it into the **Filename pattern fallback** field. Values here cannot use templated variables.
### Specifying file types allowed
You can whitelist [MIME (Multipurpose Internet Mail Extension) types](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types) by adding them to the **Allowed MIME types** field. Once a MIME type is whitelisted, the file upload will only accept that specific file type (as well as any other file type whitelisted).
The below is a list MIME types currently supported by the file upload component:
| Category | MIME types |
| -------- | ---------------------------------------------------------------------------------------------------- |
| Images |
image/gif
image/vnd.microsoft.icon
image/png
image/jpeg
image/svg+xml
|
| Video | image/mp4 |
| Document | application/pdf |
{% hint style="info" %}
You should whitelist MIME types, otherwise you may receive uploads of formats that you cannot process; i.e. if you want to allow *only* document uploads, whitelist the **application/pdf** MIME type.
{% endhint %}
### **Allowing multiple answers**
Enabling **allow multiple uploads** lets the respondent upload more than one file as an answer to a question.
# Grid choice
Ask multiple questions with the same set of choices
A **grid question**, sometimes referred to as a *matrix* question, is used to select multiple values, each with the same set of choices.
Grid questions are most commonly used when multiple answers are collected on the same scale.
If you are asking for a single choice, use a [select](/adding-questions-and-content/question-reference/select) question instead.
## Specifying choices
Similar to the select question, you can specify choices for a grid question under **SETTINGS**. There you may also specify the type of the value, whether number, string, or boolean.
The choices will be shown as options for each of the sub-questions that you define, displayed as individual columns.
#### Allow multiple selection
When **allow multiple selection** is checked a user will be allowed to provide multiple answers for every row.
### Sub-questions
To define the rows of the grid, specify the questions to ask in **SUB-QUESTIONS**. These can be [conditional](/conditions-and-logic) on previous answer values.
Each of the sub-questions will have its own [answer variable name](/response-data-collection-and-management/variable-schema#naming-answer-variables), and will otherwise behave the same as if the question were asked separately.
## Style
The grid question uses the radio or check selection from [checkmarks](/styling/customizing-appearance/checkmarks) in the style editor.
In order to further customize the grid question, you can use the [Table](/styling/customizing-appearance/tables) tab in the style editor.
# Iframe
A custom question, hosted by you within an iframe.
Formsort supports dozens of question types out of the box. However, in some cases it makes sense for you to implement a custom question type yourself using the Formsort [Custom Question API](https://github.com/formsort/oss/tree/master/packages/custom-question-api).
A great example of this would be an airline ticket purchasing flow, which at one point requires picking a seat (or multiple seats).
While you could use select buttons in a grid to achieve this within Formsort, backed by an API to fetch the choice options, maintaining the logic of which planes are in your fleet and which seats are available would be much more easily done as part of your existing technical infrastructure.
Instead of having to custom engineer the entire form flow, you can build just the single question you need and plug it into your existing flow, reusing the Formsort questions and logic for the remainder.
{% hint style="info" %}
To view various sample implementations of custom questions, check out this repo:
{% endhint %}
## Adding read-only content
The simplest custom content is read only. Once a user sees the content, they will be allowed to continue along in the flow.
This is useful if you have something like a privacy policy you need to show a user, and you don't want to link to it or have to keep the content within Formsort.
To add it, set the **Source URL** to the URL of your content, and enable **Is read-only?**.
You yourself host custom content and questions (or use something like a headless CMS to do so). During development, it's recommended to point the Source URL to localhost and view the flow in the Live preview.
## Setting the size of the container
Within the custom question settings, you can set the Default width and Default height.
If your content or question is larger than this size, the default behavior is to allow it to scroll. If you'd rather disallow scrolling, you can set the behavior in overflow-y.
### Dynamic setting of size
The `