Custom Fields for Jira Admins

Audit, deduplicate, and clean up the custom field zoo - find unused fields, duplicate fields, and screens that ship them, then bulk-edit safely.

Product: Custom Fields Audience: Jira Admins
Get Custom Fields on the Marketplace ↗

Why this matters for Jira admins

Jira’s field model is permissive by design - any project admin can create a custom field for their team’s needs, and most do. Over years, that accumulates. A typical 5-year-old Jira instance has hundreds of fields, many duplicated, many unused, and many on screens where they shouldn’t be.

The cost of the field zoo is real:

  • Performance - field count and screen field count both impact issue load and search speed.
  • Reporter friction - reporters who see 30 fields on a Create screen pick the first that looks plausible rather than the right one.
  • Data quality - duplicate fields fragment the same data across multiple columns, breaking reports.
  • Migration cost - any Cloud migration, instance consolidation, or major version upgrade is slower with a bloated field set.

Native Jira admin gives you a paginated list and a search box. That’s the entire toolset. Custom Fields adds the inventory, usage data, dedup detection, and impact-analysis pieces that make cleanup tractable.

Where to start

A practical starting workflow for new Custom Fields installations:

  1. Inventory - generate the full field list with screen counts and JQL-usage flags.
  2. Triage orphans - fields on zero screens AND no JQL in 6+ months are the easiest deletions. Usually 10-30% of the field count.
  3. Dedup - look for near-duplicate names and types. Pick a survivor, migrate data, retire the others.
  4. Restrict overweight screens - any Create screen with 25+ fields is friction. Move fields to the Edit screen if they’re not needed at creation time.
  5. Schedule the next audit - quarterly is enough for most instances. The work compounds: each pass makes the next pass shorter.

What jira admins are dealing with today

  • Older Jira instances have 500+ custom fields, most of which were created years ago by people who've since left.
  • Native Jira's Custom fields admin page is paginated and unsorted - there's no easy way to find unused fields or duplicates.
  • Atlassian's warnings about field-count performance kick in around 800-1,000 fields on Cloud, but there's no tooling to do anything about it.
  • Two teams created near-identical fields ('Severity' and 'Issue Severity') and now reports double-count.
  • Removing a field is risky because nobody knows what filters, automation rules, or screens depend on it.

How Custom Fields helps jira admins

Field inventory with usage data

List every custom field with its name, type, contexts, screens, and recent-usage indicators - which fields are queried in JQL, which appear on Create screens, which have data on issues.

Duplicate and near-duplicate detection

Find fields with similar names ('Severity' / 'Issue Severity'), identical types, or overlapping options. Cleanup becomes a deduplication pass instead of an archaeology project.

Field security and per-field permissions

Lock down sensitive custom fields to specific roles. Useful for fields holding PII, salary data, or security findings - native Jira applies field visibility through screens only, which is leaky.

Bulk field operations

Change context, screen membership, or option lists across many fields at once. The same operations are possible in native Jira admin but require clicking through every field individually.

Pre-deletion impact analysis

Before deleting a field, see which filters, automation rules, dashboards, and screens reference it. Avoid the 'I deleted it and three boards broke' surprise.

Use cases

  1. Quarterly field audit. Schedule a quarterly review of fields with no screen membership and no JQL usage in 6+ months. Bulk-delete the confirmed orphans; the inventory makes the decision quick.
  2. Pre-migration cleanup. Before moving from Data Center to Cloud (or consolidating two Jira instances), shrink the field count. Cloud's per-plan limits make this a hard requirement for many migrations.
  3. Deduplicate after acquisition. Two merged teams each had their own 'Customer Tier' field. Find the duplicates, pick a survivor, migrate data, retire the rest.
  4. Field security for compliance. Lock down fields that hold regulated data so only the compliance team can read them, regardless of which screen they appear on.

Common questions from jira admins

What's the right number of custom fields for a Jira instance?

There's no universal number, but performance starts to degrade noticeably above ~500 on Data Center, and Atlassian Cloud warns above ~1,000. The real cost is rendering: every field on a Create or Edit screen makes those screens slower, regardless of total field count. Aim to keep the count low, and aim to keep the number of fields per screen below 25.

How do I find unused custom fields safely?

Two signals together: the field is on zero screens, AND the field hasn't been queried in 6+ months. Either signal alone misses cases (a data-only field with no screen presence is still used by automation; a screen-attached field with no recent JQL is still being filled in). Custom Fields surfaces both together.

Will deleting a custom field break my JQL filters?

Yes, if the field is referenced in a saved filter. The filter won't error out - it just silently returns wrong results. Always check filter dependencies before deletion. Custom Fields' impact-analysis report shows every filter, automation rule, dashboard, and screen that references the field before you click delete.

Does Custom Fields work on Jira Cloud?

Yes. The Marketplace listing covers both Cloud and Data Center, with feature parity on the inventory and audit side. Field security (per-field permissions) works on Data Center; Cloud has different built-in mechanisms that Custom Fields integrates with.

Can Custom Fields rename or merge two fields without losing data?

Merging two fields involves moving data from the deprecated field to the surviving one, then retiring the deprecated field. Custom Fields supports this for compatible types (text->text, single-select->single-select with matching options). For type-changes (text->select), the data migration is more involved and requires explicit mapping.

Try Custom Fields for your team

Custom Fields works for jira admins on Jira Cloud and Data Center. Install from the Atlassian Marketplace, or read the main Custom Fields page for the full feature list.

Try Custom Fields on the Atlassian Marketplace ↗   See the full Custom Fields overview →

Also built for

Custom Fields solves a different problem for each team: