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.

[Mat Ward]

I'm a relatively novice Jira admin, but I was under the impression that forms provided with Jira Cloud have to use existing fields. If you need a new question on a form, you have to create a new field for it.

I recently rejected a request for a new form because it would require an additional 17 new fields to be created. Was I right to do this?

We don't have JSM or any of the form add-ons available in the marketplace.

[s.gridnevskii]

@Mat  hm, I always thought it is optional to link form fields with Jira fields. Did Atlassian change it recently? Then it is one more reason to stay in Data Center :)

[Josh]

@Mat Ward you do not need to link all form fields to Jira fields. @s.gridnevskii is right that it's optional - the behavior is the same in Data Center and Cloud.

[Mat Ward]

@Josh Any chance of pointing me to info on how to do this?

When I was playing with forms it would only let me use fields that already existed, or new ones that I created.
The docco I found indicates you can only use fields that are available for the work type - whether existing or new custom fields.
https://support.atlassian.com/jira-software-cloud/docs/add-or-remove-fields-from-your-form/

[Greg D]

@Mat Ward I think I may know what is leading to your confusion here.

Right now there are effectively two different form systems in Jira Cloud, which is why this feels messy:

1. Advanced Forms (ProForma-style) - setup lives in the Jira space settings

• Primarily tied to Jira Service Management, where they’re the standard experience
• Support form‑only fields (no Jira field required), richer layouts/sections, and form-specific automation
• Great for complex intake, service workflows, use-cases where you need more control over conditions around answers and default responses, etc.
• Allow for a many-to-one relationship between form and Jira work item (you can add a bunch of different forms to your Jira work item/request

They do work in Jira directly in some environments, but that’s usually via exceptions / special configuration these days with new sites. The catch: to submit through these forms into Jira and not JSM, you generally need a full Jira license, so they’re not ideal for broad, open intake.

---

2. Native Jira Forms – Jira Software / Work Management - setup lives on a tab (where boards, list view, calendar, etc. live)

• Started in Jira Work Management / team‑managed projects as a basic space-admin controllable create screen without much in the way of features
• Became the standard forms builder in Jira Software around the time of merging JWM into just Jira (both form settings were available at this time with advanced being a little more hidden)
• Atlassian picked these as the long‑term direction outside of JSM
• Can:
  • Act as a modern issue collector
  • Be made public via open links (woohoo)
  • Use conditional questions now (hooray)

Constraint: every question ultimately ties back to a Jira field (boo), so they don’t yet match the flexibility of the more advanced/ProForma-style forms.

---

Net result

• You lean on the advanced forms when you need serious layout options, form‑only fields, more features on intake, and tight workflow hooks (and your licensing model can handle it)
• You lean on native Jira forms when you need lighter intake and public / low-friction access in Jira Software or Work Management

Both are useful; both are limited in different ways. I went a bit deeper on the trade‑offs and parity wish list here:
Public forms are coming to Jira

I really hope that there will be a way to open up the advanced forms, have form-only fields on the basic forms, and have a controllable permission setting available in schemes that is separate from the regular create button for both of those.

[Mat Ward]

Thanks, Greg,

That clears it up. We don't have JSM so don't have access to the Advanced Forms functionality.

We're stuck with the Native Forms functionality which do have to be linked to fields.

[Greg D]

@Mat Ward you can try to reach out to Atlassian Support to see if they can resurrect the Advanced Forms on your site for Jira if that use-case is critical for you. I hope Atlassian brings both styles to feature parity soon.

[Piotr Smialek]

I agree this 700-field limit can be quite problematic for many admins.
at Deviniti, we see many admins struggling with this, so we’ve brought our Bundled Fields feature (Dynamic Forms application) from jira DC - where it’s very popular :) to Cloud.
The idea is simple: if you have too many custom fields, you can create one Bundled Field and move those requirements into it as sub-fields.

From Jira's perspective, it’s just one field, so you save a lot of slots in your limit while keeping the layout clean.

You can test it on a free trial. Check documentation here: 
https://deviniti.com/support/addon/cloud/dynamic-forms/latest/bundled-fields/ 

happy to help if you have any questions!