Campos personalizados in the Workspace side rail opens /workspace/custom-fields. Organization owners and admins manage field definitions for the active organization. Members and viewers see a permission message and cannot change definitions.
Management table
Above the table, a shared filter bar hosts a search field that filters rows by field title (case-insensitive, server-side). From Add filter you can add Entity, Type, and Group chips — each a multi-select that writes a comma-separated param (type=select_single,radio); values OR within a chip and AND across the search and chips. A field count shows how many definitions match the active query out of the total (for example 1 of 12 fields). Filter state lives in the URL and any change resets to page 1. Whenever any search or filter is active, the core-section rows are hidden so only matching custom-field definitions show; clearing the empty-filtered state removes the search and all filter params together.
The table lists every definition (system and custom) with columns:
| Column | Meaning |
|---|---|
| NAME | Display title of the field |
| GROUP | Badge: System (seeded, muted style) or Custom (accent style) |
| TYPE | Input type with the same icon as the add dialog (Short text, Select list, Checkbox, …) |
| ENTITY | Target object with the same icon as the add dialog (Test case, Test run, or Defect) |
| PROJECTS | All projects (globe-style label) when the field applies everywhere; a stacked project avatar with count when scoped to specific projects; or an italic No projects warning when scoped but none are selected |
| REQUIRED | Accent dot: filled when required, hollow when optional (screen readers still hear Yes/No) |
| ACTIONS | Edit (all rows); delete (custom rows only) |
Data loads from the organization API when you open the page. Rows are ordered with all System fields first, then Custom fields; within each group, titles are sorted A–Z.
Core defect sections
Three built-in defect sections — Description, Evidence, and Affected cases — appear as pinned rows with a Core badge when the table includes any defect-scoped field (or on their own when you have no custom defect fields yet). They are not custom-field definitions: you can rename the section title for your organization, but you cannot delete them, change their type, or scope them per project.
- Edit opens a title-only dialog (Save). When an override exists, Reset to default removes it and restores the localized product default.
- Overrides are organization data and render verbatim in every locale (the same model as custom-field option names). Untouched organizations keep localized defaults such as Description / Descripción.
- Renames apply to defect detail section headings only. Labels elsewhere (for example the Description field in the New defect dialog) stay on the catalog copy.
Add a custom field
Use Agregar campo personalizado to open the create dialog. The header carries the subtitle “Define an extra field for test cases, plans, defects, and other entities.” and the primary action reads Save field. Required fields are marked with an asterisk (*); optional fields carry no marker.
- Title, Entity (Test case, Test run, or Defect), and Type — all three marked as required
- Test run fields have one extra rule: a Test run field marked Campo obligatorio MUST carry a non-empty default value, on both create and edit. Saving a required test-run field with an empty default is rejected (
422 validation_failed,details.field = "defaultValue"); Test case and Defect fields keep the existing behavior and may stay required with no default. The rule exists because run creation must never fail for an integrator who omits a value — with a guaranteed non-empty default, an omitted required run value always resolves from it. - Enable for all projects is on by default; turning it off reveals the Projects multi-select with the helper “The field will only appear in the selected projects.”
- Placeholder, Default value, and Campo obligatorio depend on the field type (see matrix below)
- For Date picker, Default value uses the in-app calendar (not the browser’s native date control); pick a day, Clear, or Today. Stored values use
YYYY-MM-DD. - For Checkbox, the placeholder row is hidden; use Estado por defecto (Checked/Unchecked) instead of “required”
- For Paragraph, Default value is a multi-line textarea
- For Number and URL, Default value validates on save (finite number / valid URL)
- For Select list (single), Select list (multi), and Radio, open the Values tab to add options (name, Font Awesome icon class, hex color). System fields ship with canonical seed options that already include default Font Awesome icons and semantic hex colors (for example High priority uses an up-arrow with accent color). The Values tab also shows a live count of the options defined so far. Default value is a dropdown or multi-select fed from that live list
- Drag the handle (⠿) at the left of each option row to reorder. Keyboard: focus the handle, press Space to pick up, Arrow Up / Down to move, Space to drop, Escape to cancel.
Placeholder and default controls by type
| Type | Placeholder | Default value |
|---|---|---|
| Short text | Text | Text |
| Paragraph | Text | Multi-line textarea |
| Number | Text | Numeric (validated) |
| URL | Text | URL (validated) |
| Date picker | Text | In-app date picker |
| Checkbox | Hidden | Checked / Unchecked |
| Radio | Text | Dropdown of Values options |
| Select list (single) | Text | Dropdown of Values options |
| Select list (multi) | Text | Multi-select of Values options |
| User picker | Text | Hidden |
For option-based types, the default control stays disabled until the Values tab has at least one option. If you remove an option that was selected as the default, the default clears automatically. On edit, if a stored default no longer matches any option, the dialog clears it and shows a short Spanish notice.
Saving creates a Custom definition scoped to your organization.
Edit and delete
The edit dialog reuses the same chrome and the same Save field action as the create dialog, with the subtitle “Edit the properties of this custom field.” Entity and Type are shown disabled and unmarked; Title still carries the required asterisk.
- Entity and Type cannot change after create (protects stored values).
- You can update title, placeholder, default, required, and project scope. Removing a project from scope does not delete values already captured; they reappear if you link the project again.
- System rows (for example Priority, Severity, Status) cannot be deleted. You may rename the title, customize options (rename seed values, change icon/color, reorder, add user options), and adjust placeholder, default, required, and project scope. Seed options cannot be removed from the list; use Restore defaults in the edit dialog to undo customizations.
- Editing or reordering options on any field preserves stored test-case values for those options; deleting an option still drops any values that pointed at it.
- Restore defaults (system fields only) opens a confirmation dialog. Confirming calls
POST /api/v1/orgs/{orgUlid}/custom-fields/{fieldUlid}/reset, which restores the seed title, placeholder, default, required flag, and option names/icons/colors while keeping stable option ULIDs. User-added options are removed. Project scope (all_projects/project_ulids) is preserved. Test cases that pointed at removed options receive the field default when one exists, or the value is cleared. - Custom rows can be deleted only when no values exist yet; otherwise the app shows an error.
Relationship to test cases and defects
Definitions edited here drive labels and option visuals on test case and defect surfaces through the API.
For test cases, embedded customFieldValues on case GET/list responses include optionName, optionIcon, and optionColor when the stored value resolves to a known option, so the repository PRI column and editorial priority chips render Font Awesome from persisted option data without fetching definitions per row.
For defects, every organization receives seeded Severity and Priority system fields (required, with default options). You can rename options, add new ones (for example a Blocker severity), and change icons/colors — option names are org data, not fixed product copy. The same definitions appear on the New defect dialog (system fields first), in the detail Properties sidebar (severity/priority rows before assignee and other typed rows), and in the run capture flow. List and run-defect responses expose severity/priority only via systemFieldValues; defect detail GET embeds full customFieldValues. Required defect fields without a default block one-keystroke capture: Enter opens the full New defect dialog prefilled from the quick-create form instead of posting immediately.
The Restore defaults action on system fields resets option names, icons, and colors to the canonical seed map while keeping stable option ULIDs. Type labels (“Short text”, “Select list (multi)”) and entity labels (“Test case”, “Defect”) come from the product i18n catalog.