# Schema (variables)

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

<div align="left"><figure><img src="/files/T031GfDkKMhGA4s66qEK" alt="" width="474"><figcaption></figcaption></figure></div>

{% 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 %}

### Naming variables <a href="#naming-variables" id="naming-variables"></a>

You should update variable names to something that captures the semantic meaning of the information collected. For example, `first_name` is a better-named variable than just `name` since you may end up collecting multiple names in a flow.

#### Renaming <a href="#renaming" id="renaming"></a>

It's safe to rename variables within Formsort. References like templated strings or logical conditions will update automatically.

Note that if you are sending data externally (through integrations or analytics), you will want to take care with renaming, since you may have downstream dependencies that depend on an answer name taking a specific value. For example, you may have configured an email service to use `user_first_name` within an email template, which Formsort cannot "see", so if you changed the variable name to `first_name` that email template would break.

{% hint style="info" %}
See [Publishing schemas](/publishing-schemas.md) for an approach on keeping your downstream dependencies safe by requiring forms to implement particular schemas.
{% endhint %}

### Variable data types

Formsort uses standard **JavaScript data types** for all variables, including answers collected from responders.

<table><thead><tr><th width="177.63641357421875">Type </th><th width="431.27264404296875">Examples </th></tr></thead><tbody><tr><td>string </td><td><code>"Olivia"</code>, <code>"Some\multi-line\string"</code></td></tr><tr><td>number</td><td><code>5</code>, <code>3.14</code></td></tr><tr><td>boolean</td><td><code>true</code>, <code>false</code></td></tr><tr><td>object</td><td><code>{ city: "Brooklyn", state: "New York" }</code></td></tr></tbody></table>

Answer values can also appear as **arrays**, particularly when:

* You're using **repeated questions**
* A **select question** allows multiple selections

You do not need to manually assign a data type for answers collected from questions. The appropriate type will be automatically inferred based on the question type that sets the variable.

#### Subtypes

In addition to standard JavaScript data types, Formsort variables can have a **subtype**—a higher-level classification that provides additional semantic meaning. These subtypes are used internally by Formsort to apply special handling or formatting logic.

<table><thead><tr><th width="128.45452880859375">Subtype</th><th width="128.18182373046875">Base Type</th><th width="247.4544677734375">Example</th><th width="198.818115234375">Note</th></tr></thead><tbody><tr><td><code>email</code> </td><td><code>string</code> </td><td><code>"hello@formsort.com"</code> </td><td>Validated as proper email format</td></tr><tr><td><code>date</code></td><td><code>string</code></td><td><code>"2019-01-11"</code></td><td>Always formatted as ISO 8601</td></tr><tr><td><code>datetime</code></td><td><code>string</code></td><td><code>"2019-01-01T01:30:00.000Z"</code></td><td>Also ISO 8601 format, with time</td></tr></tbody></table>

These subtypes help ensure consistency across flows and enable certain features, such as validation, formatting, and classification for integrations.

{% hint style="info" %}
See [Publishing schemas](/publishing-schemas.md) for an approach on keeping your downstream dependencies safe by requiring forms to implement particular schemas.
{% endhint %}

***

## General variable settings

The settings found here are general to all type of variables (from questions, API variables, external variables, etc), and can be found in the editing menu of any of them.&#x20;

<figure><img src="/files/zXl9o6v6HCbzOSg08mbb" alt=""><figcaption></figcaption></figure>

### Readable description

It's helpful to keep your answer variable names short and succinct, since you'll be using them throughout the flow. A variable like `current_interest_rate_pct` is perfect: it describes unambiguously what is stored there.

However, if you're making a dashboard which consumes form data, `current_interest_rate_pct` might not be enough for your colleagues to understand outside of the context of a particular flow. Neither would the label of the question, which might be something intended for responders, like `What is your current interest rate, {{first_name}}?`

For that reason, it's possible to set a **Readable description** on answer variable names. You can set these to text like "Borrower's current self-reported interest rate" more suitable for downstream consumers.

[Webhook](/integrations/integration-reference/webhooks.md) payloads can be set to include the descriptions, allowing downstream systems to access the descriptions when generating dashboards, reports, etc.

### Data classification

D**ata classification** provides a mechanism for associating a variable with functional concept that may be used in or have implications for downstream integrations.

For example, setting a data classification for `responder_email` on an answer variable will enable the following behavior:

1. The answer will be treated as PII, and by default not sent to third-party integrations.
2. When the answer is collected for the first time, the `EmailCollected` event will be fired.

#### Available data classifications

| Semantic meaning              | Type (subtype)   | Description                                          |
| ----------------------------- | ---------------- | ---------------------------------------------------- |
| `responder_email`             | string (email)   | The responder's email                                |
| `responder_first_name`        | string           | The responder's first name                           |
| `responder_last_name`         | string           | The responder's last name                            |
| `responder_marketing_consent` | boolean          | Whether the responder consents to marketing messages |
| `responder_phone`             | string (phone)   | The responder's phone number                         |
| `responder_dob`               | string (date)    | The responder's date of birth                        |
| `responder_mailing_address`   | object (address) | The responder's mailing address                      |
| `responder_other_pii`         | any              | Generic personally-identifying information           |

{% hint style="info" %}
We'd love to expand this list to the most meaningful data classifications, so chat us if you'd like us to add more.
{% endhint %}

### Keep in URL if present on load

When a flow is loaded in Formsort, any URL parameters that match any answers defined in the flow will be placed into the answers and removed from the URL. To learn more about that, read about getting data in from [URL parameters](/importing-data/url-parameters.md).

If you would like instead for an answer to remain in the URL, enable **Keep in URL if present on load**. This might be helpful if you are matching up campaigns on a URL string, and want to keep things like the `utm_source` consistent across pages.

{% hint style="warning" %}
Anything in the URL will most likely be recorded by any analytics scripts you include in the integrations, so avoid using this setting for personally-identifying information.
{% endhint %}

### Storing answers in cookies

Another option is to store answers in cookies. In cases where you are collecting more sensitive information, this might be a better option, since you might not want to pass sensitive information unencrypted via URL. In order to do so, you can enable the **Read/Write in Cookie** option.&#x20;

{% hint style="info" %}
Configuring a domain is required to store answers in cookies.
{% endhint %}

### Don't send to analytics

<figure><img src="/files/mBBbj4aGjhc6kbCTr7lE" alt=""><figcaption></figcaption></figure>

Un-checking this box will prevent the answer variable from being published in the payload. By default, this box is checked.&#x20;

{% hint style="info" %}
This feature is disabled by default, as [Amplitude](/integrations/integration-reference/amplitude.md), [Google Analytics](/integrations/integration-reference/google-analytics.md), [Google Tag Manager](/integrations/integration-reference/google-tag-manager.md), and [Segment](/integrations/integration-reference/segment.md) can all be configured to send **all** data during an analytic event (see [analytics events](/integrations/getting-data-out/analytics.md) for more information). Use caution when sending all data, and use "Don't send to analytics" on a specific answer variable to protect user privacy, or prevent unnecessary data from being sent to a third party.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.formsort.com/response-data-collection-and-management/variable-schema.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.