Are there rules for using custom fields?

[Christian Gertsch]

Hi there,

We are tracking Software Bugs in Jira Software. Therefore, we need for every bug "Description", "Steps to reproduce", "Expected behavior".

I somehow have in mind, that custom fields are mainly used if you want to lay a filter on it. Thus, custom fields refer to information who could be useful if they could be filtered. 

If this is correct, it does not make sense to set a custom field for "Steps to reproduce", a custom field for "expected behavior", etc. These information will be in a free text format.

Is my understanding of the usage of custom fields correct? I am wondering if there are kind of rules which I can refer to?

Or in other words: Are there recommondations who are telling, what for custom fields should be used?

Hope this is clear enough! Otherwise I am happy to clarify!

Christian

[Simon H · Accepted solution]

We only use custom fields where we need to trigger an automation rule or we need to include the field in a Jira report. Pretty much everything else we just add as a field to a ProForma form, which doesn't rely on custom fields (full disclosure I am the PM for ProForma). 

As an example the attached screenshot shows how our support team captures all of the information for a bug in a form. More often than not we only use this form internally; however, we can also share it with the customer if we need to clarify something like the expected result. 

One of the key benefits of the form is that it helps capture all of the relevant information about a bug in a single place. This makes it much easier for our engineers when they come to investigate the issue and stops them having to wade through countless back and forth emails/comments. It also helps when there are multiple issues reported in a single query, or if a customer uses an old issue to report something new; we just had another form to cover the new issue. 

You could also checkout @Rachel Wright's work on best practices for managing Jira. She has heaps of tips and strategies. 

 

[Andrew Laden · Accepted solution]

Custom fields can also be part of conditions and validation rules, not just filters.

One tip that I wish someone had taught me early on.

When you create a new custom field, Jira will create a global context for it. Immediately go in and change that to just scope the field to the project you need it for. 2 reasons.

1: Performance improvement. Jira will not have to manage that field for any project other then the one it is intended for.

2: Hygiene. If you scope the field to just the 1 project, you never have to wonder where else it might be in use.

[Christian Gertsch]

Great, thanks! I am happy for such inputs!!

Christian

[Joe Pitt · Accepted solution]

There are no 'rules' Custom fields are useful for filter, but also for information related to the issue like justification, The one 'rule' I would say is to put JIRA under change control/configuration management. Without that lots of JIRA instances end up with custom fields with the same name because the JIRA administrator(s) may not check that a field someone requests already exists in another project. Because JIRA assigns an numeric ID to the field as the key and NOT the name it is possible to have fields with the same name which causes confusion when searching or filtering. 

[Christian Gertsch]

Hi Joe

Alright, thanks for your answer! Makes sense!

Christian