Exploration Fields

The EXPLORATIONS tab in Admin → Fields manages fields for test sessions. Exploration fields capture structured metadata when a session is created — things like the testing environment, session goal, or device under test.

How Exploration Fields differ from Test Case Fields

Create an exploration field

1. Go to Admin → Fields → EXPLORATIONS and click New Field.
2. Enter a Name. The System Name is auto-generated from it — you can edit that before saving.
3. Select a Type. All types except STEPS are available. See Field Types.
4. Set whether the field applies to All Projects or Selected Projects.
5. Click Save.

Options are not defined here. A DROPDOWN or MULTI_SELECT field gets its option list from a project override, not from this modal — there is no global option list. Save the field first, then open Overrides on its row to author the options.

System Name rules: Must start with a lowercase letter, and after that may contain lowercase letters, digits, and underscores — the pattern is ^[a-z][a-z0-9_]*$, up to 255 characters, and it must be unique in the workspace. The box auto-fills from the Label and tidies itself as you type. System Name is permanent and cannot be changed after the field is created.

Edit an exploration field

Click the Edit button on a field row. You can change:

• Name (the display name)
• Enabled state
• Project assignment scope (All Projects or Selected Projects)

Field type and System Name cannot be changed after creation. Option lists are edited under Overrides, not here.

Exploration fields have no Presentation or Behaviour section. The icon, unit, placeholder, help text and Carry forward controls described under Test Run Fields are offered for result fields only — an exploration field’s editor does not show them.

Enable and disable an exploration field

Toggle the Enabled switch on the list directly. Disabling a field hides it from new exploration creation but preserves all previously stored values.

Delete an exploration field

Click the Delete button on the field row and confirm the dialog. The dialog suggests disabling the field instead, to keep historical information.

A field with values recorded on explorations cannot be deleted. The server refuses the delete rather than removing that evidence, and says so: This field has values recorded on explorations. It can’t be deleted while those values reference it. The message arrives as an error toast and the confirmation closes. There is no force option and no administrator override — the delete is refused, not failed, so there is nothing to retry.

Explorations keep no frozen snapshot of their field values the way a closed run does, which is why the refusal here is unconditional.

Deleting a field that has no recorded values is still permanent. The definition, its project overrides, and its template links go immediately, with no undo. A value that was blanked out on an exploration may still count as recorded, because clearing the box does not always remove the underlying row.

Disable instead of deleting. The Enabled toggle hides the field from new explorations while preserving every stored value, and it works whether or not values exist.

Project Overrides

Click the Overrides button on a field row to configure project-specific behaviour — required state, default value, and option restrictions.

For full detail, see Project Overrides.

"Can I use the same field for both cases and sessions?" No — Test Case fields and Exploration fields are separate. If you need the same data captured in both contexts, create two fields: one under TEST CASES and one under EXPLORATIONS.