As a Jira administrator, I was once asked a deceptively simple question by management:
“Where is this field used?”
The goal was reasonable:
They wanted to analyze the instance, optimize performance, reduce confusion, and clean up technical debt that had accumulated over years.
What I quickly realized was that Jira makes this question surprisingly hard to answer.
The Reality of Finding Where a Field Is Used
In Jira, a field is never “just a field”.
To understand where a single custom field is used, you need to manually walk through a long and fragmented chain of relationships:
Screens path
For one field, you must determine:
-
On which screen(s) the field appears
-
Those screens belong to which screen scheme(s)
-
Those screen schemes are referenced by which issue type screen scheme mappings
-
Those mappings are associated with which project(s)
Workflow path
At the same time, you must also check:
-
On which screens the field appears
-
Those screens may be referenced by workflows
-
Workflows belong to workflow schemes
-
Workflow schemes are associated with project(s)
And this process must be repeated:
➡️ One field at a time
➡️ Manually
➡️ Across multiple admin screens
There is no single place in Jira where you can see this information consolidated.
Why This Becomes a Serious Problem
This isn’t just an inconvenience — it creates real operational risk.
1. Performance degradation
Over time, Jira instances suffer from field proliferation:
-
Dozens (or hundreds) of unused or rarely used custom fields
-
Fields attached to screens and workflows “just in case”
-
Legacy fields left behind after process changes
A large number of fields:
-
Slows issue creation and editing
-
Increases indexing and rendering cost
-
Makes configuration changes riskier
When Jira feels slow, fields are often part of the reason.
2. User confusion and data inconsistency
Another common pattern I’ve seen:
-
Multiple fields with the same semantic meaning
-
Slightly different names
-
Created by different teams at different times
-
Nobody remembers which one is “the right one”
Users ask:
“Which field should I use?”
“Why are there three fields that mean the same thing?”
This leads to:
3. Cloud migrations make it worse
During Data Center → Cloud migrations, teams often want to:
But without knowing:
…it becomes nearly impossible to make informed decisions.
The Core Jira Limitation
The core problem is simple:
Jira does not provide an overall, exportable view of field usage.
The information exists — but it’s:
This makes systematic cleanup and optimization practically unworkable.
Why I Built Fields Usage for Jira
After going through this process repeatedly, I realized Jira admins need a different approach.
I built Fields Usage for Jira to answer one fundamental question clearly and completely:
Where is each field used?
What the app does
It provides:
No guessing.
No clicking through dozens of configuration pages.
No field-by-field detective work.
Why This Is a Usefull Tool for Admins
Without field usage visibility:
-
You are blind when optimizing performance
-
You cannot safely clean up configuration
-
You cannot explain impact to management
-
You cannot plan migrations with confidence
With it:
Final Thought
Jira is incredibly flexible — and that flexibility is exactly why technical debt accumulates silently.
Fields Usage for Jira doesn’t add new complexity.
It reveals what already exists, clearly and honestly.
![Photo of Petru Simion [Simitech Ltd.]](https://us.v-cdn.net/6038660/uploads/avatars/c7/df/nc7dfc3cdcefb50b8aef7269c429d3d29.png)