You can check out the form definition spreadsheet demonstrated below here.
The other two sheets in a form definition spreadsheet are the choices and settings sheets. While you will spend less time on these sheets than the survey sheet, they are still important parts of your form design.
In this article, we will walk you through the main attributes of both the choices and settings sheets:
1. choices sheet
The second sheet is the choices sheet, and exactly what it sounds like, this is where you will set up your choice lists.
1.1 Creating choice lists
Just like the survey sheet, the choices sheet is essentially a sideways version of the online form designer. Here is the module used to add a choice in the online form designer:
And here is a choice list in a form definition spreadsheet:
You should recognize the same properties as the online form designer. Each choice that is part of the same choice list should share the same list_name.
Take a look at this example:
Here, there are two choice lists: "yesno" and "crops". The choice list "yesno" has two choices, and the choice list "crops" has five choices.
|If your form includes significantly long choice lists, consider pre-loading them from an external file instead (check out this webinar to learn more). This is a great way to optimize your form performance.|
1.2 Using choice lists
To use a choice list in a field, go to the survey sheet, and go to the field where you would like to use the choice list. In the type property of the field, enter the field type, followed by a space, followed by the name of the choice list. Take a look at this example:
This field will be a select_multiple field that uses the choice list "crops". You can use the same choice list in as many fields as you'd like.
|You can filter choices using the choice_filter property on the survey sheet.|
2. settings sheet
The settings sheet has a header row like the other sheets, but just one row of data. This sheet defines metadata about the form. Most novice users can skip this section for now, but feel free to return here later.
When you create a form using the server console, most of this data will be entered for you, so most users can leave this sheet alone. If you do think you'll need to make changes, here are the properties defined on this sheet:
form_title: Friendly name of the form. While it does not have to be unique, it is a good idea to make it unique so users can more easily recognize the form.
form_id: The unique identifier of the form, which cannot be changed after deployment. You cannot update a form on the server unless the new form definition has the same form ID as the old form on the server.
version: Version number of the form. Each new form should have a version that is lexically greater than the old form version. In the form definition spreadsheet template, the version is calculated using the date and time, so it will automatically increase every minute. If multiple form designers are working on the same form across multiple time zones, it is a good idea to work on the form in Google Sheets, so the form will use the same time zone no matter who is working on it.
public_key: If the form is encrypted, the public key to the form will go here. As mentioned earlier, if your form will be encrypted, we recommend creating the form using the server console, so there are no copy-and-paste errors. If you would like to encrypt a form after it has already been deployed, you should create a new form with a new form ID.
submission_url: This property has no specific value to the form design, it is rather a legacy security measure. Our recommendation would be to keep it as is. Your form will work perfectly well without a submission_url.
default_language: When the language assigned to field properties without a language. For example, if the default_language is "english", then when the "english" language is selected in the form, then the labels in the 'label' column will appear, as opposed to a different language's labels. To learn more, check out our documentation on form languages, as well as our support article on common multilingual form problems, and how to avoid them.
|While not included in the form definition template, you can add an 'instance_name' column to the settings sheet to dynamically name filled-in forms.|
Do you have thoughts on this support article? We'd love to hear them! Feel free to fill out this feedback form.