Based on the number of tickets and requests I had for it over the years, do you know what I think the most loved feature of Jira is? Custom fields. Do you know what I think is one of the most misunderstood features of Jira also is? Yep, custom fields. So I figured I’d spend today doing a deep dive into Custom fields, what they are, how they can be used, and what some of the best practices are around them. 

So, what are custom fields? 

A field, in Database terms, is a piece of categorized information within an entry or row.

Jira, being Database driven, borrowed this term to refer to each entry within a given issue. Reporter? That’s a field. Summary? Also, a field. Anything you can enter on an issue is considered a field.

In general, there are two types of fields in Jira. First, there are the System fields that come with Jira Core out of the box. These are entries like Description, Summary, and Due Date. Unfortunately, these fields cannot be customized or changed in any significant way. So, for the most part, you are stuck with them – but that’s okay.

But then there are the custom fields. The custom part means you, dear Jira Guys and Gals, get to define what they are, how they behave, and how they look. Having custom fields is vital to ensuring your teams can capture the information they need to do their job and then organize, sort, and report on that very same data. 

You can find the list of the current Custom Fields by going to your Admin Section -> Issues -> Custom Fields. Be aware that some of these fields are autogenerated by Apps and Applications. For example, Jira Software adds several Locked custom fields used for it to function correctly.  

Best Practices for Custom Fields

I like to compare Custom Fields to candy. They are a great way to add some functionality and usefulness to your Jira Instance in small batches. However, just like having too many sweets, including too many custom fields to your Jira instance can cause serious problems. 

Unfortunately, it’s hard to give you a concrete answer as to how many is too many. This fact is because it will depend on your system’s architecture, performance metrics of things like Network and Database, and even how far away most of your users are from your Jira system. So, as a best practice, you should have some governing around how Custom fields are added to your system. 

To start with, I would suggest you keep your Custom Field names as generic as possible. For example, let’s say you get a request asking you to add a Custom Field “ABC End Date,” where ABC is the Project Key for a specific project. I would reject this and propose we call it “End Date” instead. This way, it can be re-used for more than just the ABC Project.

Another thing you should do is you should have a current list of Custom Fields in your Documentation and make sure it’s accessible to End Users. Encourage them to use it as a “Shopping List” for custom fields. Having this list will allow them to requests fields that are already in your instance rather than request new ones all the time. I would also make it a point to go through your Custom Field list every time you get a new Field Request to make sure a similar one doesn’t already exist. Even with a shopping list available, you will get requests for similar fields. It’s up to you not to be the rubber stamp and provide some scrutiny for the sake of your Jira instance. 

Also, as one last note, every custom field should be uniquely named. I’ll go into ways to accomplish this and still have different settings per Project later, but it’s a massive headache for everyone if you have multiple fields with the same name. 

A Field’s Context, Field Configurations, and Screens…I mean, what even?

So, you’ve created some Custom Fields and are trying to get them attached to a project. What, how?

Three separate configurations must be set up correctly for you to see a field within a project. For example, you have your fields Context must be set up to allow that Project and Issue Type, your Field Configuration must be set up to show that Field, and there must be a Screen with that field present attached to that Issue Type. We’ll go through each of these, in turn, to show you what each is, how to access it, and what the best practices are around each of the items. We’ll then go into some useful tools to debug why you cannot see a given field on a particular issue.

Field Context

The first stop we’ll make is modifying your Field context. We choose this first because, by default, it should already be set up correctly for you. On your Custom Field List, click the “Actions” gear on the Field you are interested in, then click “Configure.” You should see a form to “Configure” the Custom Field.

The part we are interested in is “Applicable contexts for scheme.” This area will show you what projects and issue types this Field is allowed to be used on. By default, it should say something like “Global (all issues).”

This setting is where Jira and I will have to disagree. According to Jira (via their tool in Data Center), you should define a limited and specific context for every custom field in your instance. Setting up your field contexts like this will save time on your Index, as you won’t have to index a field for projects that don’t include it.  

However, I value Admin Time a heck of a lot higher than I value Computer time. While I recognize the value in having a clean instance, I don’t feel like going through the contexts of a couple of dozen custom fields just to add another project to my instance. So, my recommendation is to leave this context to Global everywhere you can and only limit its scope when necessary.  

So, when would you use a Field context? Well, one of my favorite use cases goes as follows. Let’s say you have a project called BERT. And BERT just *has* to be different. And let’s say you have a Single Choice Select List field, that for some reason, BERT wants different values for the Field from the rest of the company. For argument’s sake, let us also assume that you have asked, and they have a good reason for this.

Now what? As I stated earlier, you really don’t want to have multiple custom fields with the same name, so creating another field isn’t an option. Well, this is where having the different contexts works to your advantage. First, go into the default context, and select all projects EXCEPT for BERT.

Future Rodney: Correction here. Apparently the new context just overrides the global context, so having to first modify the existing context is not necessary. Updated instructions below!

First, go to your field, click the “gear”, and click “Configure.” Now go to the top and click “Add a new context.” Name this one BERT as well, and in the description, but the whole reasoning for it in there. Then under Project, Select BERT, and click Add. Now scroll down to the BERT context, and add your Options to that. Now BERT will have different options here!

Field Configurations and Field Configuration Schemes

So, you have a good context on all your fields. Next, we’ll go to the Field Configuration. This configuration is a list of custom fields and details whether they should be hidden or shown and which fields are required.

Just a note here, Required fields are just that, fields that must be filled in. If you try to create an issue without filling it in, the creation will fail and tell you which fields need to be filled in. Likewise, if you try to edit an issue to remove the value from such a field, it will also fail to save. That being said, I am NOT a fan of Required Fields. They slow down users in creating issues and getting work done. And if they get too gratuitous, users will start just putting junk data into every required Field to move ahead, making the whole point of having it required a moot point. They are necessary sometimes, but you should use required Fields very sparingly. 

Honestly, for most of my instances, I have put most projects onto the default configuration. I only create custom configurations when I need to require or hide a specific set of Fields, and I try to design it to re-use that configuration as much as possible.

Screens, Screen Schemes, and Issue Type Screen schemes.

Screens

Here we come to the part I’ve been dreading, not because it’s complicated. I am dreading this section because it’s incredibly tedious and involved all at the same time. Screens…am I right?

Screens tell Jira how to organize Fields for the end-user to see and are the lowest configuration level on this chain. Simply put, they are an ordered list of Fields. To add another field to a screen, you need to type in the Field’s name at the bottom and click on it. You can then drag and drop the Field to where you want it on the list, and you are done! No need to save; these changes are reflected in Jira in real-time. 

One trick I like to do is organize fields by tabs. As a rule of thumb here, all required fields are on the first tab, right at the top of the list. But for one organization, we have several teams using the same screens for all their projects and would pass issues back and forth to various teams as needed. So having all the fields relevant to a given team on their tab let that team know where their information was instantly, allowing them to work without the “Clutter” (their words, not mine) of everyone else’s fields. 

Screen Schemes

The next level up is a Screen Scheme. This configuration allows you to map the various screens to one of three operations: View, Edit, and Create. These three operations are as they sound, a screen attached to View will show up when an issue is Viewed, a Create screen will be shown when you hit create for an Issue, and Edit will be shown when an issue is edited.

One of my favorite tricks to do here is the Read-Only Field. By having a field only show up on the View Screen, we can make it be able to be seen by users but not edited. We can then use Automation in the background to modify it as needed. One of the most fantastic use cases I have heard of for this is the Universal Status. The Universal Status Field was a Read-Only Field that was set every time an issue transitioned. This setup allowed each Project to have its unique statuses on its workflow but allowed for global reporting for issues across the board. Indeed an excellent use case.

Another use case has a simplified form to take in requests but an expanded form for team members once they start working on it. This is done by having two different screens on Create and Edit operations, respectively. I have implemented this one several times on instances without Jira Service Management to give as close as possible to a Service Desk Experience. 

Issue Type Screen Schemes

The last configuration on this chain is the Issue Type Screen Scheme. This configuration is attached to the Project and tells the Project which screen scheme to use on which issue type. This is how you can have different screens show up for different issue types, so you are only capturing the information relevant to each Issue. Honestly, I don’t have too much to say for this last one – it’s pretty straightforward here!

Help! Where is my Field?!

So, you’ve gone through, created a Custom Field, added it everywhere you can think of, but it’s still not showing up when you click on an issue? What do you do then?

Thankfully, Atlassian gives a tool to debug just this case. As there are several places the problem can be, this tool has saved me many MANY times. For example, if you are on “Create” or “Edit,” start by going to the upper right-hand side of the pop-up, click “Configure Fields,” and make sure “All” is clicked. If it is, then click on “Where’s My Field?” This tool will then tell you for any inputted field what configuration changes need to be made to show up on that screen. If you are on a View screen, click “Admin -> Where’s my field?” to get to the same screen. If you take nothing else away from this deep dive, I hope you take this one tool with you to use.   

 

How many custom fields does your instance have?

I have seen both nightmare cases with over a thousand custom fields and instances that were nearly clean. However, custom fields are definitely one of the things that make each Jira instance unique, and seeing unique ways people are using Custom Fields is part of what makes this job interesting. So what are some of your unique use cases?

Remember, you can comment and follow us on Facebook, Linkedin, Instagram, and Twitter. There you can catch the latest from the blog, any relevant news, and updates as I have them. You can also subscribe below to get new posts emailed to you as soon as they are published. 

And as one last note, my day job is holding what they call a “Fireside Chat” on June 23rd. This will be a discussion with Box and QAD on some of the unique ways they are using Jira Service Management for non-IT teams. I plan on joining and hope to see many of you there! For details and to sign up, be sure to click here.

But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”