Schema (variables)
Use and classify answers and other data once it has been collected.
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.
Naming variables
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
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.
Variable data types
Formsort uses standard JavaScript data types for all variables, including answers collected from responders.
string
"Olivia", "Some\multi-line\string"
number
5, 3.14
boolean
true, false
object
{ city: "Brooklyn", state: "New York" }
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.
date
string
"2019-01-11"
Always formatted as ISO 8601
datetime
string
"2019-01-01T01:30:00.000Z"
Also ISO 8601 format, with time
These subtypes help ensure consistency across flows and enable certain features, such as validation, formatting, and classification for integrations.
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.
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.
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, setting a data classification for responder_email on an answer variable will enable the following behavior:
The answer will be treated as PII, and by default not sent to third-party integrations.
When the answer is collected for the first time, the
EmailCollectedevent 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
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 the Read/Write in Cookie option.
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.
Last updated
Was this helpful?