Short definition
A custom field in Jira is any field added to issues beyond Jira's built-in set of summary, description, priority, assignee, etc. Custom fields can be text, number, dropdown, multi-select, user picker, date, cascading select, or several other types. They're managed in Jira admin and exposed on screens via a Field Configuration.
What custom fields cost
Custom fields are cheap to create and expensive to live with. Each one adds:
- A row in Jira’s per-issue field table (small).
- An indexable column - for searchable types - in the Jira search index (medium).
- Rendering cost on every screen that includes it (medium - this is where most slowdown comes from).
- Cognitive cost: every reporter sees the field and has to decide what to put in it.
Instances with thousands of custom fields are common in older Jira deployments where every team added its own bespoke set without consolidating. Most installations could remove 30-60% of their custom fields with no functional impact.
Field types
The most-used types:
- Text Field (Single Line) - short string, indexable.
- Text Field (Multi Line) - long string, indexable.
- Select List (Single Choice) - one value from a defined list. Great for severity, environment, etc.
- Multi Select - multiple values. Useful for affected-components, regions, etc.
- User Picker - pick a Jira user.
- Date Picker / Date Time Picker - date or datetime values.
- Number Field - numeric. Story points, cost estimates.
- Cascading Select - parent/child dropdown (Country -> City). Powerful but easy to over-use.
- Labels - free-form tags.
Plugin custom field types add many more (sprint, epic link, team).
Field configuration: required / hidden / read-only
Whether a field is required, hidden, or read-only is decided by the Field Configuration assigned to the issue type, not by the field itself. The same field can be required on a Bug screen and optional on a Story screen in the same project, because each issue type can use its own Field Configuration.
Cleaning up the custom-field zoo
Periodically audit custom fields with no screen assignments and no recent uses in JQL. Two signals:
- Field is on zero screens - the field is data-only; nobody can edit it through the UI.
- Field hasn’t been queried in 6+ months - nobody is reading the data either.
If both are true, the field is almost certainly dead. The Custom Fields product surfaces both signals together so cleanup is a triage list, not an archaeology project.
See also (Redmoon products)
Common questions
What is a custom field in Jira?
A custom field is any field added to issues beyond Jira's built-in set of summary, description, priority, assignee, etc. Custom fields can be text, number, dropdown, multi-select, user picker, date, cascading select, or several other types. They're managed in Jira admin and exposed on screens via a Field Configuration.
How many custom fields is too many?
Performance starts to degrade noticeably past ~500 custom fields on Jira Data Center, and Atlassian Cloud warns above ~1,000. The real cost isn't the field count - it's that every field on a Create or Edit screen makes those screens slower to render. Audit periodically and remove fields that aren't on any screen and aren't queried.
What's the difference between a custom field and a screen?
A custom field is the data definition (name, type, possible values). A screen is the UI grouping that decides which fields appear on Create / Edit / View for a given issue type. The same custom field can appear on many screens, or on none.
Can custom fields be queried in JQL?
Yes. Most custom fields are searchable: `"Severity" = "S1 - Critical"`. Field names with spaces need double quotes. JQL also supports `cf[12345]` syntax using the field's internal ID, which survives field renames - useful for saved filters that shouldn't break when a field name changes.