You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
This article is part of a collaborative series on Form Design. Previous articles covered Why Form Design Matters, Form Layout and Flow, writing Good Form Questions - Open Questions and Good Form Questions Part 2 - Choice and Conditional Logic and Things to Think about When Converting Forms to Jira.
When I became a Jira administrator, the most confusing part of project administration was how screens, screen schemes, and issue type screen schemes worked together. Huh? All I wanted to do was to change a few fields around and instead, I found myself lost in a confusing combination of settings that didn’t make any sense to me. Shouldn’t it be easier? Once I understood the relationship however, I saw how powerful these settings are when they work together. Let’s start out with some simple definitions.
Screens define which fields are present and their display order. Jira Server and Jira Cloud “Classic” projects have four types of screens. They are:
You can have one screen, or one set of screens, for all issues in your project. Or you can have different screens for each issue type. We’ll talk more about that in the “Issue Type Screen Scheme” section below.
Jira Cloud “Next-gen” projects work differently however. There’s just one screen per project or per issue type and no distinction between the create, edit, and view operations. “Next-gen” projects treat empty fields differently as well. An empty field displays with the word “None” below it, as pictured.
Image: The “Start Date” field is empty, but displayed in a Jira Cloud “Next-gen” project
In all versions of Jira, screens display both standard and custom fields.
Some fields can be ordered as desired by rearranging them on the admin view of the screen. Other fields are automatically placed and grouped together. For example, all user-picker fields (“Assignee”, “Reporter”, etc) appear together on the right side of an issue’s screen. All date fields (“Due Date”, “Created Date”, “Updated Date”) also appear together on the right.
Jira Server and Jira Cloud “Classic” projects have Screen Schemes.
Remember the “create”, “edit”, and “view” operations above? This scheme associates one or more screens with an operation.
In this simple example, there’s one screen for each operation.
Image: The “Epic Screen Scheme” uses the screen called “Epic: Create, Edit and View” for all operations
In this more complex example, there is one screen for the “create” operation and another screen for the “edit” and “view” operations.
Image: The “Bug Screen Scheme” used the “Bug: Create” screen for the create operation and the “Bug: Edit and View” screen for the other operations.
A Screen Scheme can have as little as one screen shared by all operations or as many as three screens, with one screen for each operation.
I recommend starting with one screen shared by the “create”, “edit”, and “view” operations in your project. If that screen becomes cluttered with too many fields, or if information needs to be collected during different stages of the workflow, then consider using multiple screens.
Jira Server and Jira Cloud “classic” projects also have one final setting called an Issue Type Screen Scheme. This scheme associates screens with different issue types. Just like you can have different screens for different operations, you can have one set of screens for your Bugs, one set for your Stories, and another set for your Tasks.
This Issue Type Screen Scheme has two Screen Schemes. The Bug issue type uses the “Bug Screen Scheme” which has two screens. The Epic issue type uses the “Epic Screen Scheme” which has one screen.
Image: The Bug issue type has three bug-specific screens. The Epic issue type has only one epic-specific screen.
Screens, Screen Schemes, and Issue Type Screen Schemes work together to power your project. Atlassian explains this relationship in this diagram.
It look me a long time to understand these concepts. I recommend you re-read this article and experiment in your own Jira test environment, until the relationship between these settings is clear.
If you have Jira Service Desk, there’s another type of “screen” to be aware of. When Service Desk Agents login to Jira, they see the typical Jira screens described above. When Service Desk Customers login to the Customer Portal however, they see request forms.
Request forms provide a simpler and streamlined issue view, which is great for less technical audiences. Customers need no Jira knowledge to use the portal to submit their request.
In the example below, the left image shows a default Jira create screen, which contains 21 fields. The right image shows a default Jira Service Desk change request form, which contains only 10 fields. Which one looks easier to complete?
Image: A Jira change request create screen (left) and a Jira Service Desk change request form (right)
Make your screens and schemes as easy, efficient, and reusable as possible. Here are some recommendations: