Answer variables
Use and classify answers once they have been collected.
Every question that you ask of a user will result in a piece of data captured. 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.
You should update these 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).It's safe to rename answer variables within Formsort, and any references like templated strings or conditions will stay intact within the flow.
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.
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.
The data types are the javascript types:
Type | Examples |
string | "Olivia""Some\nmulti-line\nstring" |
number | 53.14 |
boolean | truefalse |
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.
Answers 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 |
|---|---|---|
email | string | |
date | string | "2019-01-11" |
datetime | string | "2019-01-01T01:30:00.000Z" |
Even more specific than the answer subtype is the semantic meaning. This provides a data classification in the real world for what an answer represents.
As a concrete example from the real estate field: you might collect a few different emails within a flow - the borrower's email, the real estate agent's email, and perhaps the borrower's husband or wife's email.
Tagging the answer keys with a data classification allows you and integrations to differentiate between them, even if the labels change.
Setting a semantic meaning of
responder_email on an answer variable will result in:- 1.The answer is considered PII, and not sent by default to third-party integrations.
- 2.When the answer is collected for the first time, the
EmailCollectedevent will be fired, regardless of where in the flow that email was collected.
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.
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.
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.
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.
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 modified 1mo ago