Project Overrides
Project overrides let you customise how a field behaves in a specific project — making it required, changing its default value, authoring its options, or renaming its step slots — without affecting the field's global definition or any other project. It is also where a DROPDOWN or MULTI_SELECT field gets its options in the first place.
There is no per-project “hide” override. Overrides change how a field behaves where it applies; they cannot make it disappear from one project. To stop a project seeing a field, drop that project from the field’s project assignment (All Projects vs Selected Projects), or disable the field for everyone with the Enabled toggle on the fields list.
What can be overridden per project?
| Override | What it controls | Applies to |
|---|---|---|
| Required | Whether the field must be filled in before saving | All field types — except a CHECKBOX Test Run Field. See Making a field required. |
| Default Value | Value pre-populated when a new case, result, or session is created | All field types |
| Options | Project-specific option list, replacing the global options | DROPDOWN, MULTI_SELECT |
| Subfields | Rename, enable/disable, and reorder the 4 step slots for this project | STEPS only |
Overrides are independent per project. Changing an override for one project has no effect on other projects. If no override is set for a project, the field's global settings apply.
Project assignment modes
When you create or edit a field, you choose how it is assigned to projects. This also affects how overrides work.
- All Projects
- The field is active in every project by default. You can add per-project overrides on top to customise behaviour for specific projects — but the field is always present everywhere.
- Selected Projects
- The field is only active in the projects you explicitly assign it to. Each assignment can have its own override environment. Projects not listed will not see the field at all.
- Mixed mode
- A field set to All Projects can also have specific project overrides. In mixed mode, the specific project override takes precedence; all other projects use the global field defaults. This is useful when you want a field everywhere but need different behaviour in a handful of projects.
How to configure an override
- Find the field on the TEST CASES or EXPLORATIONS tab of Admin → Fields.
- Click the Overrides button on that field's row.
- In the overrides modal, select the project or projects to configure.
- Set the required state, default value, options (for DROPDOWN/MULTI_SELECT), or subfield slots (for STEPS fields).
- Click Save. The override takes effect immediately for that project.
Making a field required
Required is a per-project setting: it lives in the overrides modal (as an Optional / Required pair under the OPTIONS tab), not on the field itself. A field with no override in a project is never required there.
A CHECKBOX Test Run Field cannot be required
When the field you are editing is a Test Run Field of type CHECKBOX, the Required option is disabled and the modal explains why: a checkbox has no empty state. Unchecked is a real answer, not a missing one, so the requirement would be satisfied the moment the form opened and could never actually gate anything — a required marker that enforces nothing is worse than no marker at all.
If you want testers to consciously answer, define a DROPDOWN with Yes and No options and mark that required. A dropdown has a genuine unset state, so the requirement holds.
Test Case Fields are unaffected. The restriction applies only to result (Test Run) fields. A CHECKBOX Test Case Field can still be marked required.
Requiring a result field in every project
Marking a Test Run Field required while it is assigned to All Projects is the widest-reaching change in the fields admin, so it asks first. Saving that combination opens a confirmation — Require this field in every project? — which states the real number of projects affected and spells out the consequence: testers there can no longer record a result in one tap, because every result has to go through the full result form. Quick-record, the keypad, board and table cells, Pass & next, and bulk actions carry no field values, so they cannot satisfy the requirement.
The prompt appears only when a save would newly arm that combination. Re-saving an unrelated change — a label, an option list — on a group that is already global-and-required does not re-prompt. Flipping a field to All Projects while Required happens to already be set does prompt, because that is the same change arriving by a side door. Cancelling leaves the overrides modal open on your draft so you can adjust the choice rather than losing it.
Removing an override
To remove an override and return a project to the field's global settings, open the overrides modal, select the project, and delete the override. The field will then behave according to its global definition in that project.