Are you in the loop? Keep up with the latest by making sure you're subscribed to Community Announcements. Just click Watch and select Articles.

Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Best practices for limiting the visibility of custom fields


I am administrating a medium-sized Jira Software Server with around 200 projects, 1500 users and a little over 200K issues.

I am often facing requests from project admins to modify the visibility of certain custom field for their project or group of projects they work on.

For example the "Story Points" field - some managers wanted it only for Story issue type, others wanted it for primary issue types (Story, Bug, Feature, Task), third group wanted it for sub-task issue types too, fourth group wanted it for mix of the previous groups,...,you see where I am going.

I know several ways to handle this in Jira

  • Configure the field to be applicable for all issue types and projects and then limit its visibility in certain projects by removing it from screens. My problem with this approach is the explosion of screens, screen schemes and issue type screen schemes. For example a project manager wants Story Points to only be shown on Stories and nothing else - I have to create issue type screen scheme for this project, specifiying one set of screens for stories, another for other issue types. Now since I have two screen schemes I need to create 6 screens to associate to the 3 operations (View, Create, Edit) in each screen scheme. Next week that manager will want the Story Points to appear on Bug too, but remove some other field for bugs - more screen schemes + more screens
  • Field configurations - I can hide the field in certain Field Configurations, but this approach suffers from the same weakness of the screens approach - over time the number of Field Configurations will grow and grow
  • Using Custom Field Configuration Context - that's the approach I used. I did not have explosion of screens and field configs, but now I have 4 configuration contexts for Story Points field. Each of these context is applicable to a sub-set of the projects and sub-set of the available issue types. There are 2 more problems
    • New projects, that are created with shared configuration with existing project are not automatically added to the custom field configuration context
    • Removing configuration contexts is tricky and changing the applicable context for one project is even trickier.


How do you handle such problems?

How do you balance between performance ('cause the number of screens defined in the system is affecting performance of Jira) and maintainability?

Thanks a lot for your input



Log in or Sign up to comment