Principles to follow when requested to create custom fields

[Kasturee]

Hi there. Our company uses JIRA Server and JIRA Service Desk that's used internally between Teams in the company. I am looking for some guiding principles that you may be following at your company when you are requested by Teams to create custom fields. We are way over the maximum number of custom fields recommended for our JIRA instance. The numbers have increased due to specific information required by Teams which are used for reporting purposes or to avoid back and fro between Customers (internal) and Service Desk Teams.

I understand the principles of re-use, configuring context etc. What other guiding principles do you follow to limit the number of custom fields requested to be created?

[Daniel Ebers · Accepted solution]

Hi Kasturee,

there have been many good hints in this thread already. I might add to this with the article from Rodney which he published lately. He goes a bit deeper into this topic:

• Rules of Thumb (X-post from The Jira Guy Blog)
  https://community.atlassian.com/t5/Jira-discussions/Rules-of-Thumb-X-post-from-The-Jira-Guy-Blog/td-p/1489378

You will find the information I am referring to in point 6)

Although it is not spring right now there is a good article from Daniel in which he describes how to do cleaning and housekeeping. I know your question aimed towards prevention, not cleaning up a mess - but sometimes a mixture of both is the key to success, isn't it?

• Spring Cleaning for Jira
  https://community.atlassian.com/t5/Jira-articles/Spring-Cleaning-for-Jira/ba-p/766063

Cheers,
Daniel

[Kasturee]

Thanks Daniel. Interesting Reads....going back to the basics...I like:)

[John Funk · Accepted solution]

Hi @Kasturee  - We use the add-on ProForma Forms by ThinkTilt. It allows us to put fields on a form that are not custom fields. You can link the field on the form to a custom field in the Jira database if you like, but you don't have to. 

That helps us to keep the number of custom fields down because the form is attached to the issue and can be viewed in both the JSD portal view and the regular Jira issue view. 

[Kasturee]

Thanks for the suggestion John, will have a look at the add-on.

[Niranjan · Accepted solution]

Hi @Kasturee ,

As you mentioned, reuse of custom fields is one good thing that you can recommend to teams. To make it simpler, you can document the existing fields with their types in a confluence page and make it viewable to end users, so that they can check for fields before they raise a request for new fields ( You can add a banner with the confluence page's link).

Rename any project specific custom fields ( if possible). Existing fields may be impacted. Always recommend teams to use field IDs in their names, instead of field names.

Try to create generic custom fieldnames instead of project/issue specific ones.

Identify and remove/rename unused fields.

[Kasturee]

Thank you Niranjan. What do you mean by "Always recommend teams to use field IDs in their names, instead of field names."

[Niranjan]

ah. My bad. I actually meant that teams should use the field ids in the filters, as the IDs do not change even if the field is renamed.