Customizing Jira for Business TeamsJira is a great tool for business teams because it’s so easy to customize. After all, the information a software team needs to track will be different from the information an HR team needs to track. You can create custom fields to collect information that doesn’t fit in standard Jira fields, but be careful lest you fall into a murky swamp of slow performance and more custom fields than you care to manage. In fact, Atlassian has identified the number of custom fields as the attribute which has the highest impact on the speed of the most common Jira actions.
Note: This article is one in a series written in collaboration with Rachel Wright, author of the Jira Strategy Admin Workbook. See the bottom of this post for links to the other articles in the series.
Wondering if you’ve got too many custom fields already? According to Rachel Wright, author of the Jira Strategy Admin Workbook, load time of your screens and your custom field admin page are good indicators. Also, note how long your custom field admin page scrolls.
What should you do if you’re committed to limiting the number of custom fields, but still want to take advantage Jira’s flexibility? Who should decide when a new custom field is justified? And what should the criteria be for that decision?
Source: Atlassian - Five Secrets of Jira Performance at Scale
Start by putting a process in place that project leads can use for requesting a new custom field. Use the ProForma process template or the Strategy for Jira worksheet to gather information such as the proposed field’s purpose, type, screen schema and any needed validation rules.
Then consider the following questions:
- Will the new field be used by multiple projects?
- Will you query issues based on this field?
- Will you run a report of all the values in this field?
- Will the field duplicate an existing field? (Rachel recommends publishing a list of existing custom fields and their uses to encourage users to make the most of what’s already there rather than requesting new fields.)
- Will it duplicate core Jira functionality?
If you determine that a new custom field is indeed needed, pay special attention to creating it with the correct field type, as this cannot be changed. Having the requestor provide examples of the data the field will hold will help ensure that you select the correct field type. (Or maybe you can suggest a better way to track the info altogether!) Give the new field a generic name so that the new field can be used by more than one project.
Alternatives to Jira Custom Fields
Saying no to creating a new custom field, doesn’t mean you have to say no to giving users what they need. You have a couple of other options for collecting the same data:
- Use a standard field for a custom purpose
Standard Jira fields can be manipulated to collect different data for different projects. For example, the Jira field “Labels” can be used in different ways by different teams. A marketing team using Jira to track their production of marketing assets could use the Labels field to record the marketing campaign an asset is associated with. The same field might be used in a different project by the facilities team to record locations. You can use field configuration to set a project-specific description of what should be recorded in the field, thereby prompting users to put in the right information.
- Adapt an already existing custom field
Field context can be used to make an existing custom field serve different functions in different projects. Field contexts allow you to set a default value and a defined options list for the field within a given project and with a given issue type. For instance, you could create a custom field called “category”. The HR team might use this field to store employment status and might have four options (full time, part time, casual, contractor) to select from, with full time set as the default value. The finance team could use the same field in their project, but the options could be set to record different payment methods (EFT, check, purchase order, etc.).
- Use a ProForma form
Another option is to collect the information on a form. Forms are an easy way for business teams to collect exactly the information they need without requiring changes and customizations to your Jira configuration. Teams can design, build and deploy forms that gather data structured to their needs and validated with their business rules. Many of the data points required to fulfill a request don’t need to be queried or reported on. For those that do, the ProForma form builder makes it easy to “pipe” information from a form field to a Jira field.
Finding the balance that allows you to maximize Jira’s flexibility without sacrificing performance is a key consideration when expanding Jira to business teams. ProForma can help.
Other articles in this series: