Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Best Practices: Some Quick Wins for Fields/Screens

One of the quickest ways to make an impact on your team's Jira Software usage is to make some modifications to your projects' fields and screens. But first, what are fields and screens exactly?

In Jira Software, fields allow you to track attributes of a given issue. For instance, a bug may typically have fields like summary, description, fix version, and component to describe where the bug surfaces. Screens are a grouping of fields, organized and presented to the end user on a graphical interface. For instance, here is a creation screen for a story with all of its corresponding fields.


In short, fields are the information you plug in and screens are where that information will be captured/displayed.

In this article, I'd like to cover some quick, straight out-of-the-box wins you can achieve with fields and screens. I'll also cover some best practices to carefully consider as you dive into field/screen customization.

Quick Win #1: Create a custom field and apply it to a screen

Let's assume that for every issue that you complete in your new Jira Software project, you'd like to record who the final approver of the work was, i.e. who brought the work from "QA" to "Done." To do this, you'll create a custom field that records who the reviewer was. This not only provides transparency but also traceability, allowing you to report on who gave final approval of any given work item.

  1. Toggle to the "Custom Fields" section of your Jira administration then click on the "Add Custom Field" button at the top right. (Shortcut: hit "." to pull up a terminal where you can type in the administration screen you'd like to navigate to, i.e. custom fields, screens, workflows, etc.)
  2. You'll see a variety of custom field types. Because we want to record a user, choose "User Picker" and configure the field. You might name it "Reviewer."
  3. You'll then be brought to a menu that allows you to choose which screen you'd like to place the field on. Choose the screens for the project in question. (If you're using an out of box scrum project, you'll likely see two options, a "Scrum Default Issue Screen" and a "Scrum Bug Screen." You can choose one or the other, or both.)

Now, the field should appear at the bottom of your respective screens!

Quick win #2: Rearranging your screens

Let's say that you don't want the "Reviewer" field at the bottom of your screen. To rearrange it...

  1. Toggle to "Screens" in your Jira administration.
  2. Once you're at the screens menu, locate the set of screens for the project in question and for each hit "Configure."
  3. Here, you'll be able to drag and drop your fields into your desired sequence.

It's that easy! If you'd like to add fields to those screens in the future, you can do that in screen configuration, as well.

Best Practices

When new Jira Software administrators start adding custom fields, they tend to get a little field happy. We call this "fielditis," a condition wherein administrators create screens with excessive amounts of inputs, causing their end users' eyes to gloss over. Imagine, you want to create an issue and instead you're confronted with this:


It's highly unlikely that each field is absolutely necessary. Best case scenario, your team hates creating new issues, and worst case scenario, your team completely rebels against using Jira Software at all.

Here's a brief list of considerations as you start developing custom fields and reconfiguring your screens.

  1. Only include fields you're certain you'll report on at a later date. The benefit using a field to capture information is that you can leverage it later for reporting purposes. If you have no intention of reporting on the field, the information is better reserved for an issue comment or included in the description field.
  2. Make sure to use unique names for your custom fields. It is also wise to provide a thorough description of the field's purpose. As you create more fields, it's easy to forget why they were created to begin.
  3. Make sure your screens follow a logical sequence. Screens should arrange fields in a top-down fashion that makes sequential sense to the end user.
  4. Remove unnecessary fields. Just as you can rearrange screens, you can also remove excess fields from screens. Nothing slows down ticket creation like unused fields.
  5. Consult your team. Whether you are creating fields or screens, ask your team to review your work, or better yet, plan with them. What sounds like a great idea to an administrator could just as likely be resisted by the user base.

Further Reading

Fields and screens have incredibly granular potential and this article only scratches the very surface of the feature set. For instance, you can associate certain fields with particular issue types while restricting it from others; you can create unique screens for particular issue actions (create, edit, resolve); you can adjust field behavior, making it required or optional. There are endless possibilities!

If you'd like to really wrestle with all that fields have to offer, look no further than our documentation. It's heavy reading, but if you really want to harness the power of Jira's engine, it's time well spent.

Anyone have any other tips or tricks when it comes to using fields and screens in Jira Softwaer?



Log in or Sign up to comment

Individual organizations need to set their own criteria. However, following questions are to be considered before creating a custom field:

  • Is it needed? This may sound obvious, but it’s easy to do things just because it’s cool that we can. Just because you can, doesn’t necessarily mean you should. Make sure there is a business case for collecting the data before you create a custom field
  • Does the data need to be structured? Could you solve the same problem simply by specifying what you need from the user in the hint for your description field? Is this data element something that you will query and report on later?
  • Would the field be used by different teams across the organization? When possible, share custom fields across multiple teams. You may even want to make usability across the organization as one of the required criteria for creating a custom field
  • Is there a JIRA system field that you can use? JIRA already provides a lot of options. Teams can set their own protocols for what to include in a summary field versus a description field, for how to use labels, etc.
Like # people like this

For those of you who are working to standardize or improve your organization's field configuration, the process below should help guide you.Jira Field Standardization Process.jpg

AUG Leaders

Atlassian Community Events