Short definition
A Jira screen is the configurable ordered list of fields that appears when a user creates, edits, or views an issue. Screens decide which fields a reporter sees on Create Issue and which fields appear on the issue's detail view. Different issue types and different operations (Create / Edit / View) can use different screens via Screen Schemes.
Screens are the field-display layer
A screen is not a UI design - it’s a configuration object listing which fields appear and in what order during a specific operation. The actual rendering is done by Jira; the screen just declares the list.
A screen can be assigned to up to three operations per issue type per project:
- Create Issue screen - what a reporter fills in when filing a new issue.
- Edit Issue screen - what an editor sees when changing an existing issue.
- View Issue screen - what appears on the issue’s detail view.
It’s common (and a frequent source of confusion) for a field to be on the Edit and View screens but not the Create screen - reporters can’t set it, but engineers can edit it after triage. The reverse is also possible: a field on Create only, used to capture intake context.
Screen Schemes and Issue Type Screen Schemes
The chain of indirection:
- A Screen is just an ordered list of fields.
- A Screen Scheme maps {Create, Edit, View} to one or more Screens. (You can reuse the same Screen for all three operations if you want a single form.)
- An Issue Type Screen Scheme maps each Issue Type in a project to a Screen Scheme.
- A Project uses one Issue Type Screen Scheme.
So the path from “I edited a screen” to “the user sees it” is:
Screen → Screen Scheme → Issue Type Screen Scheme → Project → Issue Type → User
If a field doesn’t appear where expected, this is the chain to trace.
Screens and workflow transitions
Workflow transitions can also be tied to a screen. When a user transitions an issue (e.g. moves it from In Progress to In Review), Jira can pop a transition screen that asks for the inputs that transition requires - a resolution code, a reviewer, a target version. The transition screen is configured on the workflow itself, not the screen scheme.
Screen sprawl
Like custom fields, screens accumulate. Instances often end up with hundreds of near-identical screens because each project’s admin made a fresh copy rather than reusing an existing one. Consolidating to a small set of canonical screens (one per issue type) is one of the higher-leverage Jira cleanups.
Common questions
What is a screen in Jira?
A Jira screen is the configurable ordered list of fields that appears when a user creates, edits, or views an issue. Screens decide which fields a reporter sees on Create Issue and which fields appear on the issue's detail view. Different issue types and different operations can use different screens via Screen Schemes.
What's the difference between a screen, a screen scheme, and an issue type screen scheme?
A screen is the field list. A screen scheme maps the three operations (Create, Edit, View) to specific screens. An issue type screen scheme maps each issue type in the project to a screen scheme. The three-layer indirection lets one project use different screens per issue type per operation - powerful, but the source of most 'why isn't my field showing up?' confusion.
Why doesn't my custom field appear on Create Issue?
The field isn't on the Create screen for that issue type in that project. Even though the field exists globally, it's only visible where a screen explicitly includes it. Trace the chain: Project -> Issue Type Screen Scheme -> Screen Scheme -> Create screen -> field list.
Can screens be shared between projects?
Yes. Screens are global objects in Jira admin. Two projects can reference the same screen, and editing that screen affects both. Many large Jira instances consolidate to a small set of shared screens to avoid configuration sprawl.