700 Field Limit seems antithetical to Field Configuration re-use

[David Yu]

I'm not sure if I'm the only person that does this, but we generally create 3 or so standard Jira Field Configurations shared amongst hundreds of projects.

If a project needs a certain new custom field, we just add it to one of the standards, and limit the context to that one project.

If another project needs it, it's as easy as just flipping the context on the field.

This pattern of usage has made our field configs rather heavy.

With this limit, it seems like we'll need to fracture our field configurations further. I can imagine a future where we have to add a shared field across 10 projects, and have to chase down 10 different field configs to add the field to. Doesn't seem too pleasant from an administration perspective.

At least we aren't forced yet to break away from standard screen scheme configurations.

[Piotr Smialek]

as marketplace vendor we see this would be problematic for many admins to avoid fracturing your configurations even further, you might want to try Bundled Fields in Dynamic Forms for Jira.

Instead of chasing down different field configs to add new custom fields, you can use one Bundled Field as a container and simply add new requirements as sub-fields within it.
It stays as one field in your Jira limit, keeps your configurations light,and you can check more details here and test it on a free trial: 
https://deviniti.com/support/addon/cloud/dynamic-forms/latest/bundled-fields/ 

[Tomislav Tobijas]

Hi @David Yu ,

I could potentially see the issue here, but the question is - among 10 different projects/spaces, do you really have 700 different fields across all of them? I'm aware that we are generalizing the topic here, but from my experience with some mid-sized and enterprise companies, we could definitely separate some batches of spaces by different areas and departments.

That being said, if we have standardized configurations (incl. field schemes), we're definitelly not talking about 700 different fields.

Let's say we have a scenario where you have things like:

Department / Area	Work type scheme	Workflow scheme	Field scheme
Software Dev - Omega	Standardized DEV Work type Scheme	Standardized DEV Workflow Scheme	Standardized DEV Field Scheme
Business Dev - Kappa	Standardized BIZ Work type Scheme	Standardized BIZ Workflow Scheme	Standardized BIZ Field Scheme
...	...	...	...

I don't see any of the standardized field configurations (and future field schemes) having more than I don't know - 200 fields max.
Anything above that just seems like administrative overload, especially if data is mainly entered manually 👀

Like, with field optimization feature, I believe we've managed to reduce everything under 400, and that's across around 20+ organizations.

Although I'm keen to hear if anyone else is struggling with this and seeing this cap of 700 being 'too small' 🤔

Cheers,
Tobi

[Arkadiusz Wroblewski]

That´s what i meant.... 700 Fields are already wild....

[David Yu]

We're doing cloud migration tests at the moment, and I can see several of our standard field configs approaching 500 fields already. This is because the fields would add themselves automatically to all field configs back in data center.

Of course no project would have at their disposal all 500 fields, this is limited by the customfield context settings.

Point being, field configs were always left alone and not really touched since we didn't really require fields...the control of the fields were left to the customfield context settings. This limit will now require us to create and juggle more field configurations in the future.

[sherax]

The 700 field limit exists to protect system performance. While it may seem to conflict with reusable configurations, it ensures stability. Optimizing and organizing fields across multiple configurations is the recommended approach.

[Arkadiusz Wroblewski]

@David Yu 

The point of the 700-field guardrail is not to reward reuse, but to limit how many fields a project/space has to deal with at runtime. Reusing the same field configuration may help from an admin/maintenance perspective, but it does not reduce the amount of field metadata Jira still has to load, process, and present for that project. Atlassian is explicitly framing these limits as performance and reliability guardrails.

[David Yu]

Sure I can understand performance aspect of it. Though many of the checks could probably be short-circuited when testing the customfield context configurations but I can only guess what's really happening under the hood.

It was nice not having to fiddle with Field Config settings, but it now seems unavoidable.

[Arkadiusz Wroblewski]

@David Yu 

I can understand you and thats a Valid point.