Most Jira admins I talk to are haunted by the same monster:
"We have hundreds (or thousands) of custom fields and nobody knows which ones are safe to delete."
If that sounds familiar, you're not alone — and there's a reason it's especially top of mind right now. Atlassian is enforcing a 700-field-per-space limit on Jira Cloud, and a major field configuration overhaul (Field Schemes, replacing the current Field Configuration / Field Configuration Scheme model) is rolling out starting very soon. The message is clear: field hygiene isn't optional anymore.
But cleanup is only half the battle. The harder question is how you stop the sprawl from growing in the first place. Here's a simple decision framework I use when someone asks for "just one more field."
Step 1: Ask what the data is actually for
Not all data deserves to be a Jira field. When a request comes in, I ask four questions:
- Will this drive cross‑team reporting? (e.g., "Show me all work items by business unit")
- Will automation or AI depend on it? (e.g., routing rules, SLA triggers, Rovo agents)
- Does it need to be searchable or filterable across spaces in JQL?
- Does this data need to survive if the work item moves between spaces?
If the answer is "yes" to any of those, it's a candidate for a real Jira field. If the answer is "no" across the board, it's intake‑only context — and it can live in a form.
That fourth question is one people miss. Form data is scoped to the form. If work items regularly move between spaces or get cloned, and the data needs to come along, a field is the safer choice.
Step 2: Prefer reuse over new fields
Before creating anything new, do the boring work:
- Search existing fields — including inactive, hidden, and context-restricted ones. Most instances have fields that were created for one space years ago and forgotten. You'd be surprised how often the field you need already exists under a slightly different name.
- Check if you can reuse a generic field by giving it better naming, a narrower context, or updated options. Atlassian's own documentation recommends naming fields generically (e.g., "Objective" rather than "Marketing Objective") so they can be reused across spaces.
If a field can safely be reused with clear semantics, do that instead. Every field you don't create is one you don't have to govern.
Step 3: When to use forms instead
Forms (whether native JSM forms or Jira's form builder) are perfect for:
- Extra context that one team cares about but others don't — like troubleshooting steps taken, or environment details for an ops request
- One‑time or short‑lived campaigns — intake for a hackathon, an office move, a vendor onboarding sprint
- "Nice to have" info that nobody will ever query in JQL — things humans read but machines don't need
Forms let you capture rich, structured detail for the people working the work item without polluting your global field list. And you can iterate on questions without schema migrations or reindexing.
The hybrid approach is often the sweet spot. You can design a form that captures 10 pieces of information but maps only 2 or 3 of them to real Jira fields — the ones you actually need for reporting or automation. The rest stays in the form as context. This gives you the best of both worlds: clean intake for requesters and a lean field schema for admins.
Step 4: Use a checklist before creating any global field
I keep a lightweight checklist that any field request has to pass. Feel free to copy this into your team's Confluence governance page or intake workflow:
Field creation checklist
- Is this needed for reporting across multiple teams or spaces?
- Is the meaning clear and stable (it won't change definition every quarter)?
- Is there no existing field that can reasonably be reused?
- Is there an identified owner who will maintain options, documentation, and cleanup?
If you can't check all four, strongly consider keeping it in a form.
That last checkbox — the owner — is the one that kills most requests, and rightly so. Fields without owners become orphans. Orphan fields become clutter. Clutter becomes the monster you started with.
I'd love to hear how other admins are handling this. How many custom fields are you sitting on today, and how many do you wish you had? If you've got a rule of thumb for saying "no" to new field requests — or something crazy and memorable about what happens when you don't say no. I'm sure we have all faced this in one way or another.
