Passing data into flows
Different ways to provide information about a responder ahead of time.
Often, you'll already know something about a responder before they even start filling out your form flow.
Avoid repetition and personalize the responder's experience by pre-filling form answers. Formsort supports three methods of passing data into form flows:
Pre-populating with URL parameters
The easiest way to pre-populate forms with existing answers is to pass them directly in the URL, using the query string. The query string appears at the end of the URL's pathname (but before a hash). It begins with a ?, and is followed by a number of key and value pairs, each separated by an & and joined with a =.
Example URL https://flow.formsort.com/client/formsort/flow/onboarding/variant/main?email=hello%40formsort.com&name=Fil#0 Host https://flow.formsort.com Pathname /client/formsort/flow/onboarding/variant/main Query string ?email=hello%40formsort.com&name=Fil Hash #0
For each value that you wish to set, use the Answer variable name as the key, and the value you wish to set as the value.
Safe and easy generation of the query string
The query string is part of the URL, and its components need to be url-safe. Characters list spaces, ampersands, and others cannot appear in URLs, and so need to be escaped. This is why in the above example firstname.lastname@example.org actually appears as hello%40formsort.com: it has been percent-encoded.
If you're using the Formsort preview window, you can also set answers and see the generated URL using the Set answers... dialog.
Detecting formatting errors
Setting multiple values
There is no single standard for setting multiple values (eg, a select question that allows choosing multiple values). Formsort handles this by allowing you to repeat the answer key.
If you have a variable named favorite_fruits and want to pre-set it to both Apple and Banana, the query string should look like this:
When adding or editing a domain under which you will be hosting flows, you may set a default query string using the Default URL params field.
This is useful if you want to parametrize a flow based on what URL a responder is accessing it from, without needing to include URL parameters in every usage of that URL. For example, if you have a flow that contains a variable named country, you can set up one domain called fr.example.com with Default URL params set to ?country=France and another domain called es.example.com with Default URL params set to ?country=Spain and those answers would be pre-set when accessing the flows, even if accessing the bare URL without any query string.
Note that default query strings don't actually appear in the URL, but are merged with any query string that does appear in the url. Answers appearing in the URL take precedence over those set in the default.
Consideration: personally-identifying information (PII)
As part of the loading sequence, and before loading any third-party analytics, Formsort strips any values that correspond to semantically-labeled answers (such as responder_email or responder_first_name), or answers that have been marked as Don't send to analytics from the URL.
This is because many third party analytics scripts will happily log the URL of an event, and since the query string is part of the event, you may be sending PII to third parties if the answer were not stripped.
Url modification is an imperfect solution
While the query string approach is the easiest way to pre-populate data into Formsort, there's always a risk of leaking information with URLs (for example, browser extensions that load before Formsort and report which URLs they are loaded on.
When working with particularly sensitive data, we recommend using either cookies or POSTing answers, described below.
Cookies require a configured domain
For security, browsers do not send cookies acrossdomains: flow.formsort.com cannot access or write cookie data on the example.com domain.
This restriction does not apply to subdomains, however: survey.example.com can read and write cookies from the example.com domain just fine.
- Enable Read/write in cookie in the schema editor for the answers you wish to read and write using cookies.
- Write a cookie, on your root domain, with a key of the variable name and a value of the answer for each answer you wish to pass forward.
- Load the flow.
If, in the course of filling out the flow, the responder changes their answer for one of the cookie-enabled answers, the cookie will be updated with the new answer.
One of the most secure ways of passing data into a Formsort flow is to POST into the form.
Normally, when you navigate to a flow URL, your browser does a GET request to our servers. GET requests do not have a payload (known as a body): when making a link, the only way to pass information to the receiving page is using URL parameters, as described above. Since the parameters appear in the URL, they are visible to not only the responder but potentially to other scripts or browser extensions that you or the responder has loaded on their flow.
A POST request, on the other hand, has an encrypted body, and is the default way to submit form data in basic HTML. Formsort supports POSTing to the flow URLs as well as GETing. A form like the following would ask the responder for a name answer, then submit it to the Formsort URL. Note that we set the name attribute to match the Answer variable name value we've defined in the flow.
<!doctype html> <html> <body> <form action="https://flow.formsort.com/client/formsort/flow/test/variant/test-post" method="POST"> <label for="first_name">Enter your first name</label> <input type="text" name="first_name" required /> <button type="submit">Let's go</button> </form> </body> </html>
POSTing hidden inputs
If you don't actually want to ask questions before redirecting to formsort, that's not a problem: just set all of the answers you wish to pass forward within the value attribute of <input> elements with type=hidden, like this:
<input type="hidden" name="first_name" value="Olivia" />
When the containing <form> is submitted, the answers will come along for the ride, just as if the responder has entered them.