nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Accepted answers

All comments

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.

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.

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.

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.

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/

bundled fields.png

David Yu

The odd thing is Field Configurations were never a performance problem in Data Center. Maybe it only became an issue in Cloud when they released "Field Layouts" so teams could customize their View/Edits screens even further? But then they didn't include Layouts in JSM projects? I don't know how to make sense of some of these decisions anymore. :-)

Rahul also made a good point about this, and I don't think there are good solutions for scaling it out. https://community.atlassian.com/forums/Jira-questions/Best-practices-regarding-new-fields-and-the-field-limit-for/qaq-p/3130759

Tomislav Tobijas

@David Yu I mean, this is a relatively new concept in cloud as well.

I can only say that even if you are above that limit in DC, it will migrate as is (if you don't optimize before) to the cloud. Meaning, you might be over the limit, so you can do cleanup after the migration, together with those optimization options.

As we standardize all other configs. I'm perfectly fine with having a structure for this as well, but yes, it might give some extra administrative work. But from my previous experience, I'd rather have this new approach, where you can have a clean slate, compared to everything thrown in one pile.

Matthew Joslin_AppFox_

Hey David!

I would argue that fracturing your field configs is the painful route - worth auditing what's actually still in use first.
In most instances that grew on Data Center, a large chunk of the fields carrying weight haven't held a value in months, or are near-duplicates that accumulated over time.

Since you're mid cloud-migration testing, running an audit on all that now will likely solve the 700 limit and also stops you carrying dead fields into Cloud in the first place (they migrate as-is otherwise).

Our tool Optimizer for Jira is pretty perfect for this. It scans every custom field across the instance and flags the unused, the empty, and the duplicated, with usage and last-touched data, so you can safely bulk-remove or consolidate instead of having to reshuffle contexts by hand.

Free trial if it's useful: Optimizer for Jira

Tal Adari

The tension is real: reusing one field across projects is the right instinct, but it doesn't reduce your field count, since the limit is about the number of custom fields that exist, not how many times each is reused. So the highest-leverage move before restructuring configs is usually reclaiming slots from fields you don't actually need.

I built a small read-only Forge app (Field Limit Guard) that does exactly this scan and flags cleanup candidates with their screen/context/filter footprint, free under 10 users. It only detects and reports though, the actual deletes are still manual. You can try it for free.

Rasmus Ersmarker

Your Field Layouts guess was close, [Field Schemes went GA on 10 June 2026] and retire field configurations and field configuration schemes entirely. The artefact you're worried about fracturing is going away regardless. Migration is automatic 6–8 weeks on continuous tracks, September for bundled.

The catch is Atlassian's own wording: the tool *"will map your existing setup"* so that available fields *"remain exactly the same."* It preserves your ~500-field debt along with everything else. That argues for cleaning up **before** the migration reaches you, not after.

Cheapest headroom meanwhile: [trashed fields don't count toward the 700]. Given yours grew by DC auto-add, a fair share is probably dead.

Disclosure: I build one of the Forge apps in this space, [FastAudit], so take this as interested. Whichever tool you use, the two things I'd insist on are that it shows the evidence behind every "unused" verdict, and that cleanup goes to Jira's trash rather than a hard delete — restorable, and it stops counting immediately.

One thing I can't find documented: does a field *hidden* in a config still count? Trashed is confirmed excluded, hidden is silent. If you get a straight answer, worth posting here.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud