A field's type decides what people can enter, how the answer appears in an entries table, and how anyone can filter by it later. You set it in the field's settings when you build a form. Choose the type for the answer you want back rather than for how the question reads: "How many people were involved?" wants a whole number, not text.
Text, numbers and yes/no
Text
A text field takes free typing, such as a name, a reference or a short description. It holds one line unless you switch on long text, which gives people a larger box for notes or a paragraph of detail. Turn on long text for anything you expect to run past a sentence.
People can filter text answers by the words they contain. If the answer always comes from a known set of values, such as a site or a severity, use a choice list instead. Every answer then matches exactly, so entries filter and group cleanly instead of splitting across different spellings of the same thing.
Numbers
There are two number types, one for whole numbers only and one that allows decimals:
Both accept negative values. A number answer can be filtered to a range, such as everything between 10 and 20, which a number typed into a text field can't.
Phone numbers, account numbers and reference codes look like numbers but belong in text fields. You never do arithmetic with them, and some of them start with a zero that a number field would drop.
Yes/no
A yes/no field asks for one of two answers, Yes or No. People choose the answer they want, and choosing the selected answer again clears it.
Marking a yes/no field required means people must give an answer either way. It does not force the answer to be Yes. In an entries table the answer reads Yes or No, and you can filter to either.
A yes/no field can reveal follow-up questions for one answer, such as asking for the police event number only when Police attended is Yes. See conditional questions.
If the question has a third honest answer, such as "not applicable" or "unsure", use a choice list with three options instead. Otherwise people pick whichever of Yes or No feels closest, and you can't tell those answers apart afterwards.
Choice lists with colours
A choice list offers a fixed set of options, and people pick exactly one. On the form it appears as a dropdown that people can search by typing. Because every answer comes from the same list, entries stay consistent and are easy to count, filter and group.
Adding options
- Add a Choice field in the form builder, or select a field and choose Choice as its type.
- Type each option straight into the form, pressing Enter to start the next.
- Drag the options into the order people should see them.
- In the field's settings, pick a colour for any option whose answer should stand out.
The first label you give an option also fixes the value stored behind it. You can rename the label at any time: existing entries keep their answer and show the renamed label.
Removing an option is different, because entries that already hold that answer are left without a matching option. On a saved form, Pyron shows how many existing entries hold the option before you confirm the removal. When nothing would be affected, the option is removed without asking.
Colours
In an entries table, an answer whose option has a colour shows as a tag in that colour. Its text switches between dark and light so it stays readable on any colour. An option without a colour shows as a neutral grey tag.
When you name an option without choosing a colour, Pyron suggests a calm one. It leaves out red and green on purpose, so an option doesn't look like an alarm or an all-clear by accident. Choose those colours yourself when an option carries that meaning, and clear the colour when an option should stay neutral.
People scanning a table read the colour before the words. If red means "act now" on one form, avoid using it for routine answers on another, and give the same answer the same colour wherever it appears.
Sharing one list between fields
When several fields on a form offer the same options, such as a list of sites for both where an incident happened and where it was escalated to, bind them to one shared set instead of typing the options twice. Each field then reads from the same list, so a change to it applies to every field that uses it. Before you edit a shared set, Pyron tells you how many fields the change will reach.
A choice list can also reveal follow-up questions that only apply to one answer. See conditional questions to set those up.
Dates and times
A date or time field holds a real point in time rather than text, so entries can be sorted by it and filtered to a range. People choose the value from a calendar or clock picker instead of typing it, which keeps every answer in the same shape.
Choosing the precision
Each date field has a precision that sets how much detail it asks for:
Pick the coarsest precision that answers the question. A monthly inspection only needs the month, and asking for a full day invites people to make one up. Year and month answers still sort and filter alongside other dates. People pick a time of day on a 24-hour clock, to the minute.
Time zones
A day-and-time answer is entered in the time zone of the person filling in the form, and everyone who views it later sees it in their own time zone. A day on its own and a time of day carry no time zone: they show exactly as entered, wherever they are viewed. Use a time of day when a time should read the same for everyone, such as a published opening hour.
Starting with the current date and time
You can set a date or time field to start out holding the current date and time when someone opens the form. People can still change the value, so this saves a step on answers that are almost always "right now".
The value is the moment the form opened, not the moment it was saved. If someone opens a form at the start of a shift and saves it at the end, the field holds the start time unless they change it.
Fixed and relative dates
A date field is fixed unless you change it: each answer is one particular day or moment. A relative date instead holds a number of days ago and a time, so the day it points at moves forward with the calendar. Relative dates suit settings that should always look back from today, such as how far back a report reads. They can't start out holding the current date and time.
A relative answer of "1 day ago" means a different day tomorrow. For any question about when something happened, use a fixed date so the answer stays true.
Multi-select lists
A multi-select list offers a fixed set of options and lets people pick as many as apply, such as every hazard present or each piece of equipment used. Each option can be picked once per answer. On the form it appears as a searchable dropdown, and the options people pick collect in the box until they clear them.
In the form builder this is the Choices type. You build the options the same way as a choice list: type each label, drag the options into order, or switch on Shared list to use one list across several fields. Giving a Choice field and a Choices field the same shared list lets one ask for the main hazard while the other asks for any others.
In an entries table, a multi-select answer lists the chosen labels separated by commas, as plain text rather than coloured tags. If an answer needs to stand out at a glance, ask for it with a single-choice field.
When you filter your entries, you pick one or more options and see the entries that hold any of them. You can also turn the filter around to leave out entries that hold any of those options, which also keeps entries where the question was left blank.
Multi-select or several yes/no fields
A multi-select list only keeps what was picked. An option left unpicked could mean "no" or could mean the person skipped it, and you can't tell which afterwards. When you need an explicit answer for every item, such as each check on an inspection, ask a separate yes/no field for each one and mark them required.
To pick several people or attach several files, use the dedicated field types for those instead. The field types catalog lists every type a form can use.