You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
As a Jira Admin, you may have run into the problem that you have been asked to create a project with a small number of Issue Types but lots and lots of fields that need to be captured. We see this often with Jira Service Desk projects, where there is a single Service Request issue type, but dozens of different Requests that all become a Service Request. The workflow for fulfilling a request for new printer toner may be the same as a request to get a new keyboard. Yes, unless we make the fields completely generic (like just using the Description field and hoping that we get the right information), we need to capture different information for each.
Now imagine that you have 30 or 40 different Request Types all using the Service Request issue type, each with 3 custom fields that are unique to that Request Type. You could wind up with well over 100 fields on the Service Request form that you present to the Agent. This is obviously a nightmare scenario.
This problem is not limited to Service Desk. We have a client who keeps about 40 different project management fields on their Jira Software issues. They make use of these fields for various types of metrics and project management reporting as well as accounting. It is important to them that these fields be available on all issues.
While there is no fixed upper-bound on the number of fields that you should allow on a screen, our experience is that when you get over 10-15, you will overwhelm your users and make it very difficult for them to function. The new Issue View in Jira Cloud doesn’t help this situation, since now all fields can appear on the form, even when they don’t contain data. You can configure them to be in the issue layout to be “hidden when empty,” but this doesn’t help when your user wants to add some data to a previously empty field and now is presented with 20 or 30 other fields that are also empty.
How should you deal with this problem?
There are several techniques that you can consider to help address “field creep”.
Separate Create/Edit/View screens so that you only show the fields that you really need at creation. If you have fields that you require at creation and should not be changed after that, remove them from the Edit screen. Since only fields that have some value will show up on your View screen, this allows you to get more control over the number of fields presented to your users.
Use Tabs. Segregate your fields into different tabs so that users can drill down into specific data sections. If you aren’t familiar with Tabbed screens, you create new tabs on same page where you add fields to the screen. Just click on the + sign next to the default tab.
Create new Issue Types that use different screens and share the same workflow. Don’t hesitate to create a larger number of issue types that better describe the real types of work that you do. Instead of just a single “Incident” issue type, you could break it into “Network Issue”, “Software Issue”, “Hardware Issue”, etc. This will better segregate your fields into smaller collections that better focus on what you need to know.
Look into an app like ProForma, that allows you to have different forms that you can add to your issues on an as-needed basis. (Disclosure: RightStar is a ProForma partner). I will be writing about ProForm more in a future post.
What techniques have you found effective in managing field creep?
Atlassian Practice Manager
69 accepted answers