A form is the set of questions your team answers whenever they log something in Pyron — an inspection, an incident, a shift handover. The form decides what gets captured and how, so the shape of a form is the shape of the information you end up with.
Forms your team fills in
Every time someone records something in Pyron, they fill in a form. The form lists the questions to answer, and the answers become an entry filed where it belongs in the directory.
A form does more than collect answers. It sets which questions appear, what kind of answer each one expects, and which answers are needed before the entry can be saved. When a required question is left blank, Pyron holds the entry back until it is filled in. This is what keeps your records consistent: two people filling in the same form capture the same things in the same way.
Different kinds of work use different forms. An inspection form asks different questions from an incident form, and each one is shaped around the entries that task needs to capture.
Fields, types and choice lists
Each question on a form is a field. A field has a label — the words the person reads — and a type that decides what kind of answer it accepts.
The type matters because it shapes both how someone answers and what can be done with the answer later. A text field accepts free writing, a number field accepts only numbers, a date field offers a date to pick, and a Yes / No field asks for a single yes-or-no answer. For the full list of field types and what each one captures, see the field types catalog.
Some fields offer a fixed list of options to pick from instead of free text — a choice list. A single-choice field takes exactly one option; a multiple-choice field takes any number. Choice lists keep answers tidy, because people pick from the same set of options rather than typing their own wording.
When the same list of options is useful on more than one field — a list of sites, say, or a set of severity levels — it can be kept in one place and shared by every field that needs it. Change the shared list once and every field that draws from it stays in step. An option can also carry a colour, which appears as a coloured pill wherever that answer shows up in a table, so a high-severity answer stands out at a glance.
Conditional questions
A form does not have to show every question at once. Some questions appear only when they are relevant, based on an answer already given. This keeps a form short: people see the questions that apply to their situation and nothing more.
A follow-up question stays hidden until its triggering answer is chosen. Choosing a category might reveal a sub-category; marking an entry as high priority might reveal a field asking why. Answer differently and the follow-up never appears.
These conditions can build on each other. One answer can reveal a second question, whose answer reveals a third, so a form guides someone down the path that fits what they are recording without ever showing the branches that do not apply. A revealed question can be required too — once it is shown, it follows the same rules as any other field.
Who builds them
Filling in forms is part of everyday work; building them is a separate job. Forms are put together by an administrator in a dedicated form builder, so the people recording entries never have to think about how a form is assembled.
In the builder, an administrator lays out the fields, sets each field's type, arranges the choice lists, and defines the conditional questions that reveal follow-ups. Once a form is ready, it is saved and becomes available for your team to fill in. To build or change a form, see input forms.