Field Types
When creating a field you choose a type. The type determines the input control shown to users and the kind of data it stores. Field type cannot be changed after the field is created.
Field type is permanent. Once a field is saved, its type cannot be changed. Choose carefully — changing a field type would corrupt existing stored values.
Available types
| Type | Input shown to users | Available for |
|---|---|---|
| TEXT | Rich-text editor — long-form prose with formatting and inline images | Case, Result, Session |
| STRING | Single-line text input | Case, Result, Session |
| INTEGER | Whole number input | Case, Result, Session |
| FLOAT | Decimal number input | Case, Result, Session |
| DATE | Date picker | Case, Result, Session |
| CHECKBOX | Boolean toggle (on/off) | Case, Result, Session |
| LINK | URL / hyperlink input | Case, Result, Session |
| DROPDOWN | Single-select from a list of options | Case, Result, Session |
| MULTI_SELECT | Multiple selections from a list of options | Case, Result, Session |
| STEPS | Step-by-step structured input with subfield slots | Case only |
TEXT versus STRING
Both hold words, but they behave differently everywhere they are shown. Choosing the right one matters more than it looks.
- TEXT is unbounded prose — a rich-text editor with formatting and pasted images. Because a paragraph cannot be truncated into a 130 px cell without becoming useless, a TEXT case field is never offered as a display-property chip, a table column, a grouping key, a filter facet, or a side-rail row inside a test run. It renders instead as its own prose block in the main column of the case, in reading order beside Description, Preconditions, and Steps — read-only there, because the value belongs to the repository case.
- STRING is a single-line, bounded value. It fits a column and reads fine as a rail row, so it stays available as a display property and a table column.
As a result field the roles differ again: a TEXT result field is an editable rich-text box the tester fills in per execution, not inherited content. It is also the only result-field type that accepts images — a tester can paste a screenshot straight into it and it uploads with the result. STRING and the other single-line types carry a plain value.
Why CHECKBOX cannot be required
A checkbox has no empty state — unchecked is a real answer, not a missing one — so marking one required would be a constraint that can never actually gate anything. The admin screen blocks it and the server rejects it.
When you need a tester to consciously answer, use a Yes/No DROPDOWN and mark that required instead: a dropdown has a genuine unset state, so it gates consistently on every way of recording a result. See Required result fields.
DROPDOWN and MULTI_SELECT options
A DROPDOWN or MULTI_SELECT field needs a list of options before anyone can pick from it. That list is authored in the project overrides modal — Admin → Fields, the field’s row, Overrides, then the OPTIONS tab.
There is no global option list. The Create Field and Edit Field modals carry no options editor at all, so a newly created dropdown has nothing to choose from until an override group defines its options. This catches people out: create the field, then open Overrides on its row and author the list there.
Each option row in that editor carries four things:
- Enabled — disabling an option hides it from new selections but preserves it in existing data
- Icon (optional) — an icon and colour from the same palette used for field icons. The picker reads Optional until you choose one; pick an icon without setting a colour and it stores the default grey.
- Value (stored) — the internal identifier. Required, and unique within the list.
- Label (shown in UI) — what users see. Leave it blank and the value is shown instead.
Up to 50 options per list; the editor shows a running N of 50 options count and stops offering Add Option at the cap.
Option icons follow the value everywhere it is rendered — including the compact chips in a run’s result history. An option with a colour but no icon shows a small colour dot; an option with neither shows plain text. The icon comes from your configuration, so the same option looks the same on every surface.
STEPS field
The STEPS type creates a structured, multi-column input — typically used to capture test steps, expected results, actual results, and notes. It is only available for Case Fields — it cannot be used for Test Run Fields or Exploration Fields.
A STEPS field has 4 fixed subfield slots. At the workspace level, these slots have default labels. Each project can customise the slots independently using Project Overrides:
- Rename a slot label
- Enable or disable individual slots
- Reorder the slots
STEPS subfield customisation is per-project. Subfield slot names and order are configured in the project override for each field — not at the global field level. This means different projects can use the same STEPS field with different column labels.