Survey: how many Custom Fields does your instance have?

[#1]

Happy Friday, admins!

I am curious, how many Custom Fields do you currently have in your Jira cloud instance?

For me, we are at 254 in an instance with 103,000 issues and 75 projects. I know that these metrics can be all kinds but I just wanted to hear from you, great admins, and gauge a little where I am at.

Have a bodacious weekend!
KGM

[Alex Gay]

Issues	1015484
Projects	1611
Custom Fields	687

[Sarah Elmer]

Interesting survey... We use JIRA not only for IT, but for every department in the corporation... from HR to Client Services to Communications to Operations to Training, etc. Having been on JIRA since 2009, we have had 700+ Issue Types, 203 Projects and 168 Custom Fields. We do try to limit the number of custom fields by naming them to be able to interact on multiple projects for various information pertaining to that project. Only the projects dealing with IT are actually swamped with custom fields and only due to the industry that we are in.

[Nic Brough -Adaptavist-]

Too many.  It's always too many. ;-)

[Abel Lineberger]

147 custom fields with 7,500 issues and 21 projects.  That's after about 2 years of real use.

We are an ed-tech oriented, content creation and delivery company, so need to capture a lot of detail around writers, video production details, etc., as well as standard software development works.  

But I am trying to whittle that number down.  Not seeing any performance issues as of yet.

[Haddon Fisher]

We are on Jira Cloud, and have 714 custom fields over 370 projects, 102 issuetypes and something like 897,316 issues.

This instance was unregulated for a while though, so we have a lot of "clean-up opportunities" :)

[Elliot Reiter]

Good morning.  Like Sarah, our Jira Cloud instance spans all areas of the company from IT to five other large Business Units.  We have close to 189,000 issues, 339 projects, and over 600 custom fields.  Most fields were created before my time on a Server instance where there were nearly two dozen Jira Admins who neglected to see if there were custom fields, they could re-use.  Rather, new custom fields were created instead.  Now, in our Cloud instance, there are only three Jira Admins, and I'm very judicious about re-using, where possible, existing custom fields.

[Susanne Harelius]

Waaaaay too many! But we have been using our DC instance since 2012 ish. Now moving to Jira cloud and we will try to limit the number of them but it is very hard when you use it throughout the whole company and in lots of different processes. 

[Abel Lineberger]

Well, I feel better.  :)

[Craig Nodwell]

I got lucky this time around.  My new client is Jira non aware, they've been using it for 3 years now but right out of the box no customizations what-so-ever.  It's a bit of a nightmare trying to follow their in house process but I'm getting there and so is Jira.....
I've created 6 so far.

[Aaron Geister]

Way to many 550 users + and I think we are at 800+ custom fields. Granted I inherited this and trying to audit it down. 

They had when I started only 250 users with over 400 plus projects. I cut that down to less than 100. The auditing is getting exhausting lol 
It does get better though!

[Kristján Geir Mathiesen]

Thank you all for sharing! Really healthy to see where others are at and just get a little better feel. I realize that some do not feel comfortable about sharing this because they might think it shows what "poor" Jira admins they are. The reality is that we all have different situations and "adopted" our current Jira instance from somebody else (or like in the case of @Haddon Fisher where Jira was unregulated for a while).

My current Jira instance is like @Elliot Reiter and @Sarah Elmer used for all kinds of requests, not just software development or IT. I also try to create field with a broad, generic name and then use context to repurpose them.

@Nic Brough -Adaptavist- hahahaha, yup always too many!

Another angle; I was hoping to use Forms with Jira Software on Create (i.e. using the Create butotn) to save on Custom Fields. Unfortunately, that use case is not support, yet, by Forms... Made me a bit sad :(

[Abel Lineberger]

@Kristjan Geir Mathiesen - Origo  - I am also trying to drive some of the more business process related workflows into Jira Work Mgmt from Jira Software, and it would be helpful if we could enforce the use of forms for issue creation, especially if we are dealing with users that don't use Jira daily, and so don't understand the importance of thinking about the data you put into an issue.

[Matt Doar]

We do quarterly reviews of our 4 node Jira Software Data Center instance. This is from the latest review. Most of the traffic is from hundreds of services, not people. Performance is ok generally.

[Ken Siskind]

I'm always trying to limit the context of custom fields so we are up to over 400 now, but many of them are limited to a particular project or set of projects for a particular business need.  We have well over 2000 users.    

[Amir Katz (Outseer)]

I had a similar situation - migrated two separate server instances to one cloud instance, ended up with approx. 1600 CFs.

Since the Jira UI is sorely lacking in providing full information about CFs, I created a (fairly large) Python project (using Jira REST API) that retrieves all CFs and for each, checks whether it is used in screens, contexts and issues.

Its output is an Excel file with all the unused fields, with full details of each.

I then tweaked the Python project and added an option to delete CFs (specified as an input parameter).

At this point, we're down to 715 CFs and I'm keeping a very tight leash on creating new CFs, trying to reuse existing ones, adding contexts for selection fields.

[Yatish Madhav]

Wow! Insightful post and comments! And agree - tons of clean up opportunities, @Haddon Fisher 

• Number of users 1200+
• Number issues 363000+
• Number of custom fields 550+
• Number of statuses 170+
• Number of workflows 130+

It would be great to know how you manage, clean and administer your instances too? Esp you @Amir Katz (Outseer)  @Matt Doar  ... We have had a number of admins that we are cutting down. BUt would like te regulate out instances too. Tips, ideas, blog posts, ...?

Thanks all
Yatish

[Sue Wilson]

For JIRA Cloud Software & Service Management combined:

16 Projects, 127 Users, 237 Custom Fields, 27,568 Issues

The cloud instance I currently work on is only ~2-3 years old for my organization.  

I try to re-use unused custom fields or suggest using what already exists in creative ways where possible to avoid getting too carried away with having too many custom fields.  I've worked with instances where multiple custom fields named the same or very similarly, used exactly the same way, or simply created as different types (text, drop down, etc) existed just because a previous admin or 'Project Lead' didn't have the knowledge, understanding, or access to review what was already there.  Clean up is always a challenge, but worth it to reduce the maintenance nightmares that can be caused with all the 'extras' that can find their way into an instance.

[Amir Katz (Outseer)]

Following up @swilson comment - for all CFs that have identical or very similar names, I went ahead and renamed them to make them distinct. I have not notified anyone about it. If this will break any filters, workflows or automations, I'm sure that I will hear from the affected people. So far - crickets...

We even had a custom field called 'Labels'. In my mind, this is a gross incompetence (add more four-letter words here) of the culpable Jira admin - How couldn't he/she know that Labels is a system fields?

Sorry to be harsh, but I also blame Atlassian, who, even today, allows you to create custom fields with existing names, including names of system fields.

This is a huge incompetence on their part and shows lack of understanding of the work and responsibilities of the Jira admins.

If there is any bug/feature requests to fix that, they should get off their backside and fix that ASAP.

[Anne Saunders]

Users: 48 (+5 service accounts)

Projects: 151

Issues: 5,154

Custom Fields: 97

Statuses: 90 (Eek!)

Workflows: 19

I'm a mean admin who doesn't let people get very custom because we have a lot of cross functional teams, so our boards need to be expectable and manageable. That said, I'm not our first admin, and I have been slowly cleaning up for a year now.

[Nic Brough -Adaptavist-]

@Amir Katz (Outseer) - I agree with you on the custom field name problem.  There was a time when you were blocked from duplicate names, but sadly, Atlassian chose to let people break their stuff by allowing them.  It's worse in Cloud, where fields are not shared objects for team-managed projects, so you end up with loads of duplicates and no way of knowing which one you're supposed to report on.  (It's a big reason I tell people never to use team-managed projects - they're not suitable for organisations with over 25 users)

[Kristján Geir Mathiesen]

I agree with @Yatish Madhav , thank you all for very insightful comments. Good talk going on here!

[Haddon Fisher]

+1 to @Amir Katz (Outseer) and @Nic Brough -Adaptavist- when they point out the naming issues. I have less of an issue with allowing Jira instance admins the ability to name custom fields the same; they at least understand what they're getting themselves into, and I could see a few places where contexting alone would not cut it.

The minute they introduced team-managed projects though the cat got out of the bag...it was a cougar, and started mauling everything in sight.

Some shameless plugs for:

- JSWCLOUD-18756: "Restrict Team-Managed (Next-Gen) custom fields name if already exists another custom field with the same name"

- JRACLOUD-79212: Archiving Team Managed Projects Should Hide Their Fields

- JSWCLOUD-21477: Ability to disable team-managed project