All Docs
Custom Fields

Custom Fields

Custom fields let a project keep its own classifications on test cases — TestRail custom_* fields, qase severity/layer/behavior, Zephyr components, or anything your team tracks that Lathe has no column for. Fields are project-level and case-only in v1: each project defines its own, and only test cases carry values.

Defining fields#

Admins define fields in Project Settings → Custom fields (the project:update permission — the same gate as the rest of project settings).

Each field has:

  • Key — the API/export-facing slug (severity, automation_tier). Set at creation; it never changes.
  • Label — what people see in forms and columns (free to rename later).
  • Type — text, long text, number, single select, multi select, checkbox, date, or URL.
  • Options — for the select types, up to 100 choices. Option ids are stable, so renaming a label never rewrites values.

Limits: up to 50 active fields per project, labels up to 60 characters. There are no required fields — a case never blocks because a field is empty.

Archiving, not deleting. A field you no longer use is archived, not deleted. Values already on cases stay readable, the field disappears from forms, filters, and the API — and archiving never touches stored values.

Filling fields in#

Every field appears as one control in the case editor (new and edit): a text box, number input, date picker, checkbox, or an option picker for the select types. Clearing a field empties it; the case simply stores no value for that field.

The case detail page shows the values alongside the standard fields, and the Test Library can add any field as a column and filter by it — pick the columns with the column picker, per project.

Importing fields#

The import wizard maps any column your export file carries to a custom field:

  • Map a column to an existing field.
  • Or to "New custom field" — pick the type; for select fields the options are collected from the file's distinct values. The dry-run report shows exactly what will be created before you commit.

Vendor exports with known custom columns (TestRail custom_*, qase severity/layer/behavior) are suggested automatically. Export → import round-trips values losslessly: CSV export writes one column per field (header = label) with select values as their labels, so the file re-imports into the same fields.

Custom fields and the API#

API keys can read the schema and read/write values — useful for syncing classifications from automation or a migration script:

  • GET /projects/{id}/custom-fields — the active schema (keys, types, option labels).
  • GET/POST/PUT on /projects/{id}/testcases — custom_fields reads and writes in the wire format ({ "severity": "High" }, select values as labels).

There is intentionally no API to create or edit definitions — field design stays a human decision in Project Settings. See Docs → API Reference → Custom Fields for the request shapes and error reasons.

← All DocsSettings →