> ## Documentation Index
> Fetch the complete documentation index at: https://docs.quiva.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Fields and elements
> Every control a form can place — which ones each field type accepts, what each one stores, and the headings, notes and cards that go around them
Everything on a form is one of four things: an **input** bound to a schema field, an **object group**,
a **repeater**, or a **presentational element** that asks for nothing.
***
## Inputs
A field's schema type decides which controls it can wear. The editor offers only compatible ones, so
you cannot accidentally put a date picker on a number.
| Schema type | Controls offered |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- |
| **Text** | Text, Textarea, Email, Select, Multi-select, Multi-toggle, Chips, List, Date, Date range, Phone, Country, Multi-country, Uploader |
| **Number** / **Integer** | Number, Currency, Slider |
| **Yes/No** | Toggle, Checkbox |
| **List** | Chips, List; **Multi-select** as well when the list has a fixed set of allowed values; **Uploader** as well when it is a list of text |
| **Object** | Key-value |
When a field is placed without a control being chosen, it gets the default for its type: text fields
become a **Text** box, numbers a **Number** box, yes/no a **Toggle**, lists **Chips**, and objects a
**Key-value** editor.
### What each one stores
A single string. **Email** looks like a text box but rejects anything that is not a valid
address when the field has a value; leaving it empty is governed by *required*, not by the email
check.
A choice from a fixed list. These need **two** things set up, and both live in the inspector:
the allowed values on the field itself (under **Validation**), and the human-readable choices on
the placed input (under **Options**, each an internal value plus the label people see).
Set the allowed values and forget the choices and the control renders empty. Set the choices and
forget the allowed values and nothing is checked. Set both with different value lists and every
selection is rejected as *must be one of the allowed values*. Author them together, with
identical values.
These are multi-valued controls, but on a **text** field they store their answers as one
comma-separated string. The control expands it for editing and re-joins it on save.
If you want a genuine list in the data — to count it, to check a minimum number of items, or to
read it item by item — type the field as a **list**, not as text.
A number. Currency and Slider are presentation over the same value: currency adds the symbol and
decimal handling, the slider adds a track with a minimum and maximum.
True or false.
A date, or a pair of dates. Minimum and maximum dates are set under **Validation**.
A country code, or several. The list can be narrowed to a chosen set, and shown with native
names alongside English ones.
**Chips** collect short values as removable tags. **List** gives an add/remove list of plain
values. **Key-value** edits an object as name/value pairs, for the cases where the shape is not
known in advance.
Attaches files to the record. Its settings cover where files are stored, the upload button and
dropzone wording, the maximum number of files, the maximum size of each, and which file types
are allowed. The file count is checked on submit; going over it blocks the form.
### Settings on a placed input
The inspector splits an input's settings into groups, and which groups appear depends on the
control:
| Group | Holds |
| ---------------- | --------------------------------------------------------------------------------------------------- |
| **Settings** | Label, placeholder, helper text, spacing below, default value, and control-specific display options |
| **Options** | The list of choices, and how it is sorted — choice controls only |
| **File storage** | Where uploads are kept — the Uploader only |
| **Validation** | Required, minimum and maximum, decimal places, date bounds, item and file limits |
The presentation settings live on the field **as placed on this form**, not on the Record Set. The
same field can carry a different label, a different placeholder and a different control on two
different forms.
A minimum, a maximum or a maximum item count set on the *control* shapes what the control lets
someone do — it does not police what a record may contain. A value written by the API or by Abbie
bypasses the control entirely. If a limit genuinely matters, set it on the field's schema too.
***
## Object groups
Place a field whose type is **object** and that has known properties, and the form draws a bordered
group headed by the object's title, with every one of its members rendered as its own input,
recursively.
That is one node on the canvas doing the work of many — quick to place, and it stays in step with
the schema automatically when a member is added.
**The members are not separate elements.** They cannot be given their own control, their own label,
or their own conditional rule; a rule placed on the group applies to the group as a whole. If any
member needs its own treatment, place each member individually instead of placing the object.
***
## Repeaters
A **Repeater** collects a list of things, each with the same set of fields — line items on an
equipment request, sites on a supplier record, people on a visit report. It binds to a field typed
as a **list of objects**, and you lay out the fields of one item inside it; the person filling the
form then adds as many items as they need.
Its settings:
| Setting | Effect |
| -------------------------------- | ------------------------------------- |
| **Label** | The heading above the list |
| **Required (at least one item)** | Blocks submission with an empty list |
| **Min items** / **Max items** | Bounds on how many items can be added |
| **Collapsible** | Whether each item can be folded away |
| **Collapsed by default** | Whether items start folded |
A repeater cannot contain another repeater. For a genuinely two-level list, hold the inner list on
the item as a **Chips** or **List** field.
Fields inside a repeater belong to the item, not to the record — which matters when you write a
conditional rule on one. See
[rules inside a repeater](/forms/form-rules#rules-inside-a-repeater).
***
## Presentational elements
These render text and structure. They are never bound to a field and never store anything.
| Element | What it is |
| -------------------- | -------------------------------------------------------------------------------------------------------------------- |
| **Heading** | A section title, in one of six sizes, left/centre/right aligned |
| **Paragraph** | A block of rich text |
| **Note** | Smaller rich text, optionally truncated after a set number of lines |
| **Link** | Clickable text pointing at a web address, with an optional note beneath it |
| **Alert** | A coloured callout with a title, body text and an icon. Its type is Info, Success, Warning, Error or None |
| **Card** | A box around a group of rows, with a border, an optional coloured accent bar, rounded corners and an optional shadow |
| **Collapsible card** | The same, with a header the reader can fold away, and a choice of whether it starts open |
Cards are containers: they hold rows laid out exactly like the top level of the form.
### What a rule can change on each
Presentational elements can be driven by [form rules](/forms/form-rules) too — usually to make a
warning appear, or to change what it says.
| Element | Rules can drive |
| ---------------- | -------------------------------------------------------- |
| Heading | Visible, Text |
| Paragraph, Note | Visible, Text |
| Link | Visible, Link, Underline |
| Alert | Visible, Title, Text, Type, Show icon, Icon |
| Card | Border, Shadow, Rounded corners |
| Collapsible card | Border, Shadow, Rounded corners, Note, Text (its header) |
**Neither card kind offers a Visible rule in the editor.** To make a section conditional, put the
rule on the **row** that contains the card. A card that carries one anyway — written by hand, or
inherited from an older form — now behaves properly: hiding it clears the fields inside it and
their required-ness with them. See
[what conditional visibility does and does not clear](/forms/form-rules#what-conditional-visibility-does-and-does-not-clear).
### Shared value sets
* **Size** — Extra small, Small, Medium, Large, Extra large, Huge
* **Alignment** — Left, Centre, Right
* **Alert type** — Info, Success, Warning, Error, None
* **Card accent** — None, Primary, Success, Warning, Error
* **Border** — All sides, Top, Bottom, Top & bottom, Left