Features · Custom fields
Fields for the way you work
Eight validated field types, defined per project, searchable like everything else.
Every team tracks something the standard fields don't cover — a severity, a customer, an environment. Custom fields let your project admins add exactly those fields, per project, without touching the database schema. Values are stored as JSONB on the ticket, validated server-side by type, and searchable from the same query language as everything else.
What you get
- Eight field types — Text, number, date, select, multi-select, checkbox, user and URL — enough to model most processes without a plugin.
- Defined per project — Project admins create fields in project settings with a name (unique per project, case-insensitive), a required flag and, for selects, a list of options.
- Validated on the server — Every value is checked against its type before it is stored: numbers must be numbers, dates must be ISO yyyy-MM-dd, URLs must be http(s), select values must match the defined options, and user fields must reference a real account.
- Searchable with TQL — Query any custom field by name with cf["Field Name"] using =, != or ~ (contains) — the translator resolves the name and matches the JSONB values directly in Postgres.
- Everywhere tickets are — Custom fields render on the create-ticket form, the ticket detail page, and as extra columns in the sheet view, where most types edit inline.
- Feeds the portal too — Customer request forms can bind questions to custom fields, so portal answers land as structured, validated values on the ticket instead of free text.
No schema changes, no migrations
Field definitions live in one table; the values live in a single JSONB column on the ticket, keyed by field id. Adding a field to your project is a settings change, not a database migration. Values are keyed by the field's id rather than its name, so each project's fields stay fully independent — two projects can use the same field name without their data ever colliding.
Query custom data like built-in data
TQL treats custom fields as first-class: cf["Severity"] = "High" filters exactly like status or assignee, and the ~ operator does a contains match on the stored value. Custom-field comparisons support =, != and ~, and combine freely with AND, OR, NOT and ORDER BY in the same query.
Grows with your configuration
Custom fields plug into the rest of the configuration layer. Screens place them into per-type ticket forms, cascading selects let a parent select narrow a child select's options, and reusable field schemes let an org admin define a set of fields once and apply it to any project — synced by name, never overwriting fields you already have. Field creation and deletion are recorded in the configuration audit log.
Query it
project = CORE AND cf["Severity"] = "High"See Iskue on your own screen
A demo takes half an hour. A pilot runs on your servers, with your data, from day one.