Variables

Use and classify answers and other data once it has been collected.

Every question in your form has an associated variable where that answer is stored. To more reliably refer to the data, both in your own systems as well as within Formsort, each question's answer is given a variable name based on the question in which it is collected.

Similarly, data passed into a form, calculated with a function, received from an external API, or loaded from the form itself is stored as a variable.

You should update variable names to something consistent that is not verbose but 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).

Naming variables

Renaming

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.

See Publishing schemas for an approach on keeping your downstream dependencies safe by requiring forms to implement particular schemas.

Data types

You do not have to specify a data type for answers that come from questions: answer variables will have them set depending on which questions set them.

Formsort uses javascript data types:

Additionally, any of the answer data types can appear as an array, if using repeated questions, or with a select question that allows multiple selection.

Subtypes

Variables can also have a subtype that is internal to Formsort, and is a higher-level type than the primitive data types listed above.

Subtype	Type	Example

Data classification

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

For example, etting 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 EmailCollectedevent will be fired.

Available data classifications

We'd love to expand this list to the most meaningful data classifications, so chat us if you'd like us to add more.

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 payloads can be set to include the descriptions, allowing downstream systems to access the descriptions when generating dashboards, reports, etc.

Other settings

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.

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.

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.

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 Read/Write in Cookie option.

Configuring a domain is required to store answers in cookies.

Don't send to analytics

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

This feature is disabled by default, as Amplitude, Google Analytics, Google Tag Manager, and Segment can all be configured to send all data during an analytic event (see analytics events 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.