As a Jira administrator you should choose your custom fields carefully. Too many fields are a headache to maintain. In our custom field series, we’ve shared our tips for battling custom field bloat, auditing your fields list, and reducing your field count. Now we’d like to share some custom fields we recommend that you do create.
In Keeping It Clean: Containing Jira Custom Field Growth we recommended sharing custom fields with different teams across the organization. These 7 fields are intended to be used by many teams in many Jira projects.
Recommended Custom Fields
1. Requested
Field type: Date Picker
Create a “Date Picker” type field and name it “Requested.” Place this field on a project’s “Create” screen and use it to answer the question “When would you like this request completed by?“
This field is different from the “Due Date” field, which signifies when the team can actually accommodate the request. The “Due Date” field should be populated after a request is reviewed for understanding and prioritized. In most cases, that field should not appear on the initial “Create” screen.
Consider this scenario: The Legal team needs an update to the terms and conditions page on the company web site. They create an issue for the Development team with a requested date of March 15. The Development team receives and considers the request. Since it’s of “Medium” priority, they slide the change into their next release, which is March 22. These two fields have easily helped convey urgency and communicate ability.
Recommendation
Always place the “Priority” field before a requested date field on a screen. Collecting the importance before a date is entered may help set realistic expectations.
2. Category
Field type: Select List (multiple choices)
The built-in “Components” field is a great way to categorize (and automatically assign) work. But what if you need a second categorization method? Create a “Select List (multiple choices)” field and name it “Category”. This generic name is important and ensures that the field can be used to cover many scenarios.
Custom Field Context
Next, use Jira’s “Contexts” feature to display different selection values in different projects. For example, the Legal team categorizes their work with selection values like: Contract, Service Agreement, Litigation, etc. The Security team
categorizes their work with options like: Denial of Service, Information Disclosure, and Injection. Using a custom field context allows you to use one field to support many scenarios.
Recommendation
Always add an “Other” selection to cover all potential non-listed responses.
3. Department
Field type: Select List (single choice)
Which department generates the most requests for your team? That’s useful information for reporting! Unfortunately, Jira doesn’t know information like a user’s department name, team name, manager’s name, or phone number. While it is possible to store these additional details in a user property, there’s no easy way to leverage that data without custom development.
Instead, create a “Select List (single choice)” field and name it “Department.” Create one selection value for each department in the company and ask the reporter to choose the appropriate one on the “Create” screen. Easy!
4. Team
Field type: Select List (single choice)
Same as above. Create a “Select List (single choice)” field and name it “Team.” You could also couple the concept of “Department” and “Team” in one field by using the “Select List (cascading)” type. First the user chooses a department and they choose their team from a sub-set of selections. Now you have an easy way to query who the work is for.
5. URLs
Field type: Text Field (multi-line)
It’s common that Jira issues are related to data from other websites and applications within and outside the company. For example, the Development team may need links to vendor documentation for their integration project. The Facilities team may need a link to the purchasing policy Google Doc for large equipment orders. The HR team may need to link to an employee’s record in a third-party employee resource application. When external applications are integrated with Jira, linking is easy. But what do you do for all those other applications that aren’t connected?
Create a “Text Field (multi-line)” field and name it “URLs.” Users can enter an unlimited number of links to other online areas without the need for one custom field per URL. Jira will even make the URLs clickable on an issue’s “View” screen, as shown in the screenshot.
6. IDs
Field type: Text Field (single line)
Sometimes you need to associate Jira issues with records in other offline or inaccessible applications. For example, a purchase order number from desktop accounting software, an ID in a vendor’s system, or a serial number on a piece of equipment. Just like the URLs field above, individual custom fields are often overkill. Instead, create a “Text Field (single line)” field and name it “IDs.” Users can enter ID numbers as comma separated values.
7. Notes
Field type: Text Field (multi-line)
Finally, sometimes users need to enter more information that doesn’t belong in the standard “Description” field. Create a “Text Field (multi-line)” field and name it “Notes.” This generally named field can be used in different ways in different projects. Use a Field Configuration scheme if you need to provide a project or issue-specific field description.
Now there’s no need for an “Information” custom text field, an “Instructions” field, or a “Business Justification” field. All those lovely details can go in a single field.
Recommendation
If you’re not planning to query for or report on a piece of information, don’t devote a custom field to it.
Conclusion
Carefully planning your custom fields makes Jira administration easier. Creating generic fields for use by multiple teams is an easy way to support the needs of your users and limit the custom field count at the same time.
Which custom fields do you use across multiple projects? What strategies help you reduce the need for custom fields? Share your tips and tricks in the “Comment” section below.