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:
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.
