Designing Jira Fields in 2026: When to Add a Field vs. Use Forms

[#1]

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:

1. Will this drive cross‑team reporting? (e.g., "Show me all work items by business unit")
2. Will automation or AI depend on it? (e.g., routing rules, SLA triggers, Rovo agents)
3. Does it need to be searchable or filterable across spaces in JQL?
4. 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.

[John Dunkelberg]

Good guidance, but a caution on the field reuse in Step 2.  If you have a field you start to use for two different groups, and their usage starts to diverge (different options for your single select, for instance), then you now have an extensibility challenge because they are entangled.  It also become all the more important that both groups are aware they can't count on being the only user.  For instance, they may have queries such as "myfield is not EMPTY" that assumes they'll only get returns of issues (ahem *work items*) in their purview.  Yes, ideally queries are bound by project, but you can't assume user-written queries follow that, and it becomes more problematic with scale.

[Pooja Chauhan]

These are good suggestions, especially the idea of maintaining a checklist both for the end user requesting new fields and for admins from a governance perspective.

However, my main concern relates to what is mentioned in Step 2. The concern is not only about the field name, but also about the field type. There are cases where fields with the same name and generic purpose can be reused across multiple spaces, but this becomes challenging when the required field type differs.

For example, one team may require a Short Text/Plain Text field with a specific name, while another team may need a Drop-down (Single Choice) field with the same name. Since Atlassian currently does not provide an option to change the field type after creation, we are often forced to create a new field solely because the type does not match the requirement. This ultimately leads to duplicate or very similar fields being created on the platform.

[s_gridnevskii]

For Service Management another option would be to use assets fields. They can easily be reused in many projects since its type is the same for any asset. Another great feature is that we can give service agents an opportunity to edit assets in a specific Schema and they can change options available on the field without jira administrator.


Also we have the following receipts that allows us not to use many fields:

 - It is possible to extract data from form after issue creation and put its value into Description. We do that a lot. This way data becomes searchable by JQL (~text).

- Some fields may be used on Create screen only. Same procedure - after issue creation we can copy their values into Description. This does not reduce the number of fields, but rather cleans up user view and edit screens helping to concentrate on valuable fields.

[Robin Surland]

In my org it was forms that was driving the need for additional custom fields, so when we stood up a new "managed" instance I created a set of "generic" fields for all the issue types for use in forms. Yes, their data falls into these fields and each team needs to know what data is actually in Request_Dropdown1, but it is working for the teams. Now I just need to add contexts for teams, not new fields for forms. 

[Josh]

Excellent article, @Greg D .

@s_gridnevskii assets fields definitely help tame the chaos, especially since the field contexts can be user flexible. There are some downsides (e.g. values aren't passed in filter subscriptions, AQL in JQL can be a bit overwhelming at first), but they're still super helpful.

I'm looking forward to the upcoming field schemes change that will allow multiple custom field contexts within a single space, which will help cut down on field sprawl even more.