Variables (answers)
Use and classify answers and other data once it has been collected.
To more reliably refer to the responder data, both in your own systems as well as within Formsort, every question in your form has an associated variable that responder's answers are stored in - these are considered variables from questions.
Similarly, the following Variables return values that are stored in variables as well, even though their mechanism of resolution is different:
Externally provided
API lookups
Calculated inline
System library
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.
See Publishing schemas for an approach on keeping your downstream dependencies safe by requiring forms to implement particular schemas.
Data types
Formsort uses javascript data types for all of the different Variables:
Type
Examples
string
"Olivia"
"Some\multi-line\string"
number
5
3.14
boolean
true
false
object
{ city: "Brooklyn", state: "New York" }
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.
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.
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.
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
We'd love to expand this list to the most meaningful data classifications, so chat us if you'd like us to add more.
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.
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.
Last updated
