Diagnostic TeardownATLASSIAN
The Jira Field Exists. Why Can This User Not See It?
- Author
- Alex Florian
- Published
- Updated
- Reading time
- 4 min
An employee can see a field's value on a Jira work item but cannot find that field when making the change they need. An administrator points to the field in the site-wide list. Both are describing real observations, but the second doesn't explain the first.
The useful comparison keeps the person, work item, field, and attempted operation fixed. A field existing somewhere in Jira is only the beginning of the question; the configuration must make it available in this particular context and interface.
This guide concerns Jira Cloud company-managed work. Newer screens may call projects “spaces.” Team-managed configurations have a different path, and a site undergoing field-management changes may not match an older screenshot.
Identify the field-management experience first
As checked on September 8, 2026, Atlassian is progressively replacing field configurations and field-configuration schemes with field schemes. In the new experience, schemes control field availability by work type and space, while contexts control such things as defaults and dropdown options. Don't use the older claim that context alone determines visibility as a universal rule. [4]
If the site still uses the older experience, inspect the applicable context and field configuration alongside the operation's screen and layout. On a migrated site, start with the associated field scheme's availability for the affected work type, then inspect the relevant presentation settings. [2][3][4]
The question stays stable across those arrangements: is the field available for this work, and where is this operation supposed to display it?
Follow one missing field rather than trying several settings
Consider a hypothetical field named Validation reference on a Bug in the PAY project. The employee can see its recorded value but cannot find it in a particular transition dialog. A transition is a move from one workflow status to another.
That contrast directs attention toward the interface for that move, rather than proving the field is missing everywhere. The transition may use a screen different from the main work-item layout. Finding the field on the normal view therefore doesn't establish that the transition includes it. Screens, scheme associations, and the work-item layout have distinct roles in the applicable configuration. [2][3]
A compact investigation would distinguish these findings:
| Finding in the illustrative case | What it suggests checking |
|---|---|
| Field unavailable for the affected work type | Its availability in the active field-management model |
| Field available, but absent from this transition | The screen or presentation attached to this move |
| Field visible, but the user cannot perform the move | The action's permissions or workflow rules, not field existence alone |
| A similarly named field appears elsewhere | The exact field identity before reusing or editing it |
An administrator can also use Jira's Find your field diagnostic from an affected work item where that option is available. Atlassian documents the option as requiring Jira administrator permissions. It can help expose blockers, but its result still has to be interpreted for the site's active experience and the operation the employee attempted. [3]
Test the smallest explanation that fits
Suppose the comparison establishes that the appropriate field is available but missing from the transition's assigned screen. If the intended process requires the employee to enter it there, adding it to that specific screen is a more justified proposal than creating another field or broadening availability across the site.
The approval to change the process is separate from discovering the current configuration. A deliberately unavailable operation isn't necessarily a defect. Clarify what the employee should be allowed to do before treating every restriction as something to remove. [1]
After the change, repeat the original transition as the relevant user and check a nearby case that should be unaffected. That establishes whether the proposed cause actually explained the complaint. If several unrelated settings change at once, a field reappearing tells you much less about what was necessary.
Keep a brief account of the field identity, operation, cause, and correction with the request. The next missing-field report may have a different cause; what is reusable is the comparison, not a remembered toggle.
The employee's problem is solved when the required information is available at the right moment in their actual work. The administrator's list proves that a field exists. The user's successful operation proves something considerably more useful.