Best practices regarding new fields and the field limit for February

Question

As some of you know in February 2026 there will be field limit implemented and those projects with 700+ fields will not have the possibility to add more fields.

Diving a bit in this issue, we realize that is not per project, it´s per Field Configuration, and the field configuration is linked to 1 or more projects via the Field Configuration Scheme.

When you have 300+ projects in your instance and you add all the projects to the same field configuration scheme, and therefore to the same Field Configuration you probably are above, very above the 700 fields per project limit. Because each project has it´s particular needs.

That´s one part of the problem.

The other part of the problem is if you have more than one Field Configuration, every time you add a new custom field, by default it will be added to all the Field Configurations at once.

With both of those intros in mind my questions are:

* What´s the best practice to keep a balance between number of Field Configurations and number of projects in the instance when you have a couple of hundred of projects?

* What´s the best practice when you add a new field, to have less impact on the number of fields by field configuration?

Extremes are, in my opinion good examples and that´s why I will use some extreme examples next.

If we have 1 Field Configuration for all the projects, it´s easier to maintain, but it will be well above the 700 fields.

If we have 1 Field Configuration per project, we will have 300+ fields configurations, and we might have the risk to remove each new custom field from 300+ fields configurations manually to use it only in 1 place. Just to avoid reaching the 700 field per project limit.

Any ideas / tips / links that could help?

Thanks in advance

Sascha H_ · Answer

Hi @Raul de la Barrera ,

i feel like there is another layer to this before the previous two answers come into play...

The field configurations provide the means to.... well... configure your fields.

You can define renderers for text fields there, you can make them mandatory "globally" like summary, or you can make fields hidden there, so they are not accessible for the functionalities you invoke when clicking around in Jira.

For the best balance between number of projects and number of field configurations I'd say:

As much as needed and as few as possible

As much as needed addresses the variations in needs of your projects. One project wants field "Input" mandatory and others not => separate field configurations.

As few as possible addresses your need of maintaining all of this. Here you are asked to apply project contexts, keep fields' names generic, etc.

Cheerio,

Sascha

John Funk · Answer

Hi Raul - Welcome to the Atlassian Community!

I agree with Trudy and her thoughts. And here's a few more from me.

Use more generic names for your fields so that they can be used across multiple projects.

Use meaningful Contexts - meaning not Global for every field. Don't add a field unless there is a particular person requesting it for a particular project. Document that somewhere so that you can periodically come back to that field to see if it is still be used and can contact the person who requested it. Also add just that Project to the Context for that field. If another project wants to use it, then just add that project to the Context.

Also, if the person requesting the field is not planning on using that field in a report somewhere, then why are requesting it? If no one else is going to look at the values in that field, then you probably don't need that field.

Trudy P Claspill · Answer

Hello @Raul de la Barrera

Here are my thoughts:

1. Can you reduce the number of custom fields by having projects share common custom fields and defining Contexts per project, rather than each project having its own custom fields. It has always been my opinion as a Jira Administrator that unchecked proliferation of custom fields is a bad idea. It is better to question the business need (or problem needing to be solved) behind the request for a custom field and then see if there is an existing field that can be reused/shared.

2. Do you have some projects that are similar so that you could shift to having a small number of Field Configurations with each one being shared by a subset of projects, where you can eliminate unnecessary fields from the configuration based on the project subset needs?