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; } } }

Your Jira has more custom fields than you think. And now there's a limit.

Peter Kerrigan

Quiz Time!

Quick test: without looking, how many custom fields does your instance have?

Many admins guess somewhere between 50 and 100. Then they open the admin screen and find 400. I've seen instances with tens of thousands (yes, you read that right). Nobody planned for that. It just happened, one reasonable request or Cloud-to-Cloud merge at a time.

Custom field sprawl is the most common configuration problem in Jira, and it's also the most fixable. Here's a manual audit process you can run in an afternoon, no apps required.

Why sprawl happens

Three reasons, usually in combination:

Every team requests fields, and saying yes is easier than pushing back
Nobody ever deletes anything, because nobody is sure what's safe to delete
Admin turnover: the person who knew why "Region_v2_FINAL" exists left in 2023

The cost is real. Every field with a global context loads on every issue. Field pickers get longer, screens get slower, and users start filling in the wrong "Start Date" because three of them exist.

This stopped being optional in 2026

For years, sprawl was a someday problem. Not anymore. Atlassian now enforces hard limits in Jira Cloud: 700 fields per field configuration and 150 work types per scheme. Cross the field line and you're blocked from associating new fields until you clean up. And another wave of limits and guardrails lands in September 2026.

The catch most admins miss: the 700 limit isn't really per project. It's calculated from the field configurations associated with your projects. If 300 projects share one field configuration scheme, they share one field-budget. One team's sprawl becomes everyone's ceiling.

Atlassian shipped tooling alongside the limits. The field configuration schemes page now shows field counts, warns you as you approach the limit, and offers an Optimize scheme flow to strip unused fields and create leaner scheme variants. If you haven't looked at that screen since last year, start there. It also makes the rest of this audit easier.

Step 1: Get the full inventory

Go to Settings > Work Items > Fields. This screen has improved a lot: you can now see screen count and context per field, and sort by them.

For anything beyond eyeballing, pull the list via the REST API:

GET /rest/api/3/field

This returns every field, including type, schema, and scope. Drop it into a spreadsheet. That spreadsheet is your audit workspace for the rest of this exercise. Keep the scope attribute, it matters in step 5.

Step 2: Find the duplicates

Sort your spreadsheet by field name. Duplicates jump out immediately:

Same name, different capitalization ("Start Date" vs "Start date")
Same concept, different wording ("Client", "Customer", "Account Name")
Versioned names ("Priority_v2", "Priority - NEW")

Flag every cluster. You can't merge them yet (Jira has no native field merge), but you can pick a survivor per cluster and mark the rest for retirement.

Step 3: Check actual usage

A field on 12 screens might still hold zero data. For each suspect field, run the following in the JQL search:

"Field Name" is not EMPTY

The result count tells you whether the field carries real data or is just furniture. Don't run this for all 400 fields; run it for your duplicate clusters and for anything with zero screens. That usually covers the worst offenders.

Step 4: Hunt the global contexts

This is the step most audits skip, and it's the highest value one. On the custom fields screen, check each field's context. A field with a global context applies to every project and every issue type, whether they need it or not.

Fields created in a hurry almost always get global contexts, because it's the default path. Restricting a field to the projects that actually use it is often a bigger performance and usability win than deleting fields outright. And with the 700 limit calculated at the field configuration level, context discipline is now how you protect your budget.

Step 5: Don't forget team-managed projects

Team-managed projects are the blind spot in most audits. Their fields are created by project admins, inside the project itself (Space settings > Work types > Select your work type), with no global admin approval and no field configuration involved.

What that means in practice:

Every team-managed field is a real, distinct custom field in your instance. If five projects each created a field called "Client", that's five fields with five silos of data that will never report together in JQL.
They have their own, much lower limit: 50 fields per team-managed project.
They show up in your API export with a project scope. Filter your spreadsheet on the scope attribute to separate them from company-managed fields. The count that's left is often the surprise of the whole audit.

You can't clean these up centrally, field decisions live with each project's admin. What you can do is find the outliers (a team-managed project at 45 fields is a company-managed project in denial) and start the conversation with that team.

Step 6: Retire safely

For fields with no screens and no values: Jira Cloud moves deleted custom fields to trash, and you can restore within 60 days. That safety net means you don't need to be paralyzed by "what if something breaks."

For fields with data but no clear owner: don't delete. Remove them from screens first and wait a cycle. If nobody screams, retire them next quarter. If someone screams, you just found the owner.

Step 7: Stop the bleeding

Creating a proper intake process for future requests will prevent you from falling into same situation again. Three questions to ask before approving any new field request:

Does an existing field already cover this? (Check the spreadsheet)
Which projects actually need it? (Scope the context accordingly, never global by default)
Who owns it? (A name, not a team)

That's it. No committee, no forms. Just three questions that kill 80% of duplicate requests at the door. And now they protect a hard limit, not just your sanity.

What I'd love to hear

What's the highest custom field count you've inherited? How close are you to the 700 line? And did you ever find out what "Region_v2_FINAL" was for? Drop your war stories below.

Comments

Davit Mkrtchyan - Be On Time

Hi Peter @Peter Kerrigan -

This is a masterclass in Jira hygiene. The "Region_v2_FINAL" is a universal trauma that every admin has experienced at least once.

I would like to add one thought on the "Why sprawl happens" section.

In my experience, custom field sprawl is rarely just about "saying yes" to requests. It is often a symptom of a deeper Governance Gap.

Many teams use custom fields as a poor man's governance tool. They try to force Jira to do things it was not natively designed for - like tracking resource capacity, labor rates, or complex portfolio dependencies. They create a field for "Allocation %" or "Project Cost" because they are trying to turn a task tracker into a professional resource management system.

The danger is that these fields are not just "clutter" - they are a signal that the organization has outgrown the standard toolset. When you try to solve a resource problem with a custom field, you are not just adding to the field count, you are creating a data silo that is impossible to report on accurately at scale.

My advice to anyone running this audit: when you find a cluster of "strange" fields, do not just ask "Do we need this field?" Ask "What business question are we trying to answer with this data?".

If the answer is "Who is over-allocated across my projects?", then the solution is not a better field intake process, but a move toward actual resource governance.

Great share, Peter. This will save a lot of admins from some very stressful afternoons!

Apryl Harris

I like it, @Peter Kerrigan

To the Community
1. Be aware of what is an Atlassian field (which will sometimes be indicated by "customfield" and the org's own custom fields. Deleting Atlassian fields can cause unnecessary app integration issues.

Another field/scheme cleanup opps:
1. Establish governance to review requests and make recommendations toward similar, more generically named fields (when possible).

2. When a space archives. Sometimes teams feel strongly about changing fields when the space is active. But, after it archives, the team is typically less concerned.

Davit Mkrtchyan - Be On Time

Hi Apryl @Apryl Harris -

Great points on the technical side. The "don't delete Atlassian system fields" warning is a lifesaver for anyone new to the audit process.

It is interesting how the "archived space" window you mentioned is often the only time organizations are willing to actually clean up their logic. It proves that the friction of changing a process while it is live is often higher than the cost of maintaining a messy system.

s_gridnevskii

I guess if Atlassian makes templates for Description I will be able to persuaded users to get rid of most custom fields. A typical example - description of bug:

System: xxx

Steps to introduce: xxx

Probability: 100%

...

Right now users need 3 or more fields to fill. If we had easy to use template that exists just on issue create screen and is copied to Description then number of fields can be reduced. It can be just like forms in service desk that have nice constructor and basic value sanity checks.

Anyway I of course reuse fields of same type in different projects. And always ask user if he is going to search issues using the field. If the answer is no I recommend him to use description.

Dennis Grochowski_uvc1yp

We experienced something very similar... Requested to postpone the limit enforcement since also agile work foresees planning cycles which this extreme limitation was definitely not a part of in the past.

Knowing we would need to invest a lot of time and effort finding all the fields not needed anymore, we started looking manually into the field configurations and keeping all braincells together while looking at a screen which look always the same with just different names – for millions and trillions of configurations.

(Although we didn't experience any performance issues at all)

This is not possible for entire days and only a few people can REALLY do it, since not everyone is involved in every field creation and project work. So we figured, we'd need to use the Site Optimizer. That sounded like a god-sent present but was in fact just not usable.

With

- thousands of fields
- hundreds of configurations
- dozens of schemes

the site optimizer wanted to create a new set of every configuration for EACH SPACE which would, on one hand, optimize the configuration (as intended), but on the other, creating loads of unnecessary individual space configurations which would cause mid-term admin trauma when trying to troubleshoot why certain fields are not available anymore for spaces...

In the end I ended up writing python code, extracting all fields with ids, names, last used, screen usage, field config usage, etc and figured it would be helpful if we simply removed all fields programmatically:

- fields not used on screens (and not needed for any hidden automations)
- field values updated longer ago than 1 year
- cleaning up all historical trash like "customfield_name (migrated x)" from the migration to the cloud

All in all, we were again forced to push other topics away to keep up with restrictions that Atlassian simply throws at us. We did it, but I can tell, users and admins were not happy with it. Many things could've been done better in terms of preparation and advisory from Atlassian on how to handle things but sadly this was not the case.
I guess that's the mode we need to get used to.

Rune Rasmussen

For step 3 be aware that this won't work for fields with a default value.
Then it is tempting to try and use the CHANGED operator, but that only works for a small handful of default fields.

Tanya Christensen

@s_gridnevskii

The Description field can be contexted in order to set such default information:
Configuring contexts and default values for the Description field

The need for separate fields is based on if the content searched or reported on. You can't build a Chart from content within a Description, but you can from most fields.

Fields are important for the operation and reporting within Jira, but proper governance is the key to ensuring Jira works for the general user base. If the users feel frustrated they will seek other ways to get their job done.

Becker_ Rene

Thanks for the share.

But there is one thing that I did not quite understand in step 3:

When there are projects, that share the same configuration, that includes the fieldscheme and fields. And said projects actually use these fields as intended - for example let's say "Customer Name". Will the field be counted as 1 field overall or is there something that actually counts it as multiple fields?

Why I am asking this, is because we automatically create customer projects and they are using the same configuration. No distinction (because none needed and we like to do changes centralized).

I am with you on creating dedicated field schemes. I am doing that for non-standardized projects - but they are quite few. Some 95% are standardized. There are 3 or 4 standards used over ~800 projects / spaces. While the bespoke projects use a good part of the fields.

We avoided context at all but and we do not have duplicate fields and I only inherited a few contextualized fields (2 or 3 fields, nothing major). In total we got ~600 fields, some 10 or so pending for deletion.

So to the point: Since I did not really get how the budget is calculated, could you please explain it with the example I've given? I'd really appreciate it.

---

Michael Brändel

We currently have >3k custom fields in our instance, including those from team-managed projects. One consequence was that we stopped allowing team-managed spaces.

Another was that we put higher scrutiny on new custom field requests, following some principles:

Reuse over create:
Always look for existing fields before creating new ones. If a similar field exists, prefer reusing it.
Field names should be descriptive, concise, and as generic as possible.
Limit Scope: use global context only if the field is generic enough to be potentially shared across spaces
Traceability & Auditability: We introduced a formal process and documented each request for custom fields.

Brita Moorus

I've also seen cases where teams had several fields for almost the same thing, like “Customer”, “Client”, and “Account”. It makes reporting and cleanup much harder later.

My usual question is also: will someone need to search, filter, report, or automate based on this value? If yes, a new field may make sense. If not, it probably belongs in the description, form or a template.

My main takeaway: before creating a new field, always check if an existing one can be reused. And if a new field is really needed, make sure it has a clear owner and is not global by default.

Less fields, less mess later 😄 Thanks for a great article! 👏

Peter Kerrigan

Based on what you've described:

If all those customer projects share the same field configuration scheme, Customer Name counts as 1 field toward the 700 limit; it is not counted once per project. The budget for Company Managed projects is calculated at the field configuration scheme level, not the project level, so a field shared across 800 projects via one scheme still only takes up one slot.

So with ~600 total fields across your 3-4 standardized schemes, that ~600 is the number that matters against the 700 cap, not something multiplied out by your ~800 projects.

Hope this helps! Please let me know if I missed the mark with my answer.

Becker_ Rene

Thank you. That answered my question. :-)

---

Matthew Joslin_AppFox_

The fastest way to find safe-to-retire custom fields is to sort your field export by two signals at once - last-used date and screen/context count. A field with zero screens and no value changes in the last 12 months is almost always retirement-ready, and that combination catches far more than either signal alone.

Two things I'd add to the manual process above. First, the team-managed blind spot is real, those fields never share a config, so five projects each with a "Client" field is five distinct fields eating your budget. Second, "is not EMPTY" undercounts fields that carry a default value, so cross-check anything that looks unused before you delete.

If pulling last-used and screen usage by hand across thousands of fields isn't practical, Optimizer for Jira surfaces those signals automatically.

Rasmus Ersmarker

No war story from me, I come at this from the tooling side rather than from a 3,000-field instance.

One refinement on the mechanic, because Becker_Rene's question is the one that trips people up. Atlassian's guardrails page words it as "Fields, 700 per space (fields included in field configuration schemes associated with the space)". So the ceiling is per space, and sharing a scheme means sharing a count, not sharing a pool.

Your conclusion still holds: add a field to a scheme 300 spaces use and all 300 move a step closer. But it matters in the other direction, another team's sprawl doesn't touch my space unless we're on the same scheme, and splitting a scheme doesn't "free up" budget for anyone. It just lets each resulting scheme carry fewer fields.

Worth adding to the cleanup list too: trashed fields don't count toward the 700, so trashing buys headroom immediately without restructuring anything.

Disclosure: I build a Forge app in this space ([FastAudit], so read that as interested.

Nick Helzer _HelzBrand_

Great write-up, Peter. One practical detail for Step 7: question 1 ("Does an existing field already cover this?") is where most duplicates slip through, because the obvious search misses the variants. When checking, search Settings > Work Items > Fields for the abbreviation and the plural too ("Cust #", "Customer Number", "Customer Numbers"), and put the reason a field exists in its description, so the next admin can answer question 1 without guessing.

Disclosure: I built Unison, an app that automates that first question. You type the proposed name and it scores it against every existing field, catching case, punctuation, plurals, word order and common abbreviations, and shows why each match fired. https://marketplace.atlassian.com/apps/427298721/unison-duplicate-custom-field-prevention-for-jira

たけのこごはん

Disclosure: I build Field Sweep for Jira, a small Marketplace app, so take the last paragraph with that in mind.

One thing that helped us before touching the 700-field limit: the "screens" count tells you where a field can appear, not where it is used. A field with zero screens can still be referenced by saved filters (JQL), board configuration (the board filter, quick filters, estimation and rank fields) and dashboard gadgets. Deleting it breaks those silently. The reverse is also true: a field on 40 screens that no filter, board or dashboard references is usually a safe delete candidate.

So the useful inventory is: for each custom field, the list of filters / boards / dashboards that reference it, plus the last-used date where Jira gives you one. You can build that with the REST APIs (search filters by JQL text, board configuration, dashboard gadget configuration) and a spreadsheet; it takes an afternoon for a few hundred fields.

If you would rather not script it, Field Sweep for Jira does exactly that scan (read-only, admin-only, Runs on Atlassian so nothing leaves your site) and exports the result as CSV: https://marketplace.atlassian.com/apps/439033528/field-sweep-for-jira . It does not delete anything; you still do that in field admin, which I think is the right place for it.

Welcome!

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

Quick Links

Find more posts tagged with

custom-field

jira-cloud

administration

governance

atlassian