Hi Jira community, I'd like to learn how Jira administrators manage custom fields as their Jira instances grow. Over time, custom fields can accumulate across projects, and it can become difficult to track who owns each field, why it exists, whether its purpose is documented, and when it was last reviewed. I'd appreciate your advice on a few questions: * How do you currently audit and organize custom fields in Jira? * Do you track field ownership, business purpose, and review history? * How do you identify fields with similar names that might serve overlapping purposes? * What information do you wish you could see when reviewing a custom field? * Do you use built-in Jira features, spreadsheets, scripts, or third-party apps for this process? I'm part of the development and marketing team behind Field Review for Jira, a Jira Cloud app designed to help administrators review custom-field ownership, purpose, criticality, lifecycle status, review history, configuration context, and governance signals. We're trying to understand the real challenges Jira admins face and what would make this process easier. I'd genuinely appreciate your experience, suggestions, and feedback. If you'd like to see what we're working on, here's the app: https://marketplace.atlassian.com/apps/3892667460/field-review-for-jira Thanks in advance for sharing your thoughts!

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

How do you manage custom-field sprawl and governance in Jira?

Real MIS

Hi Jira community,

I'd like to learn how Jira administrators manage custom fields as their Jira instances grow.

Over time, custom fields can accumulate across projects, and it can become difficult to track who owns each field, why it exists, whether its purpose is documented, and when it was last reviewed.

I'd appreciate your advice on a few questions:

How do you currently audit and organize custom fields in Jira?
Do you track field ownership, business purpose, and review history?
How do you identify fields with similar names that might serve overlapping purposes?
What information do you wish you could see when reviewing a custom field?
Do you use built-in Jira features, spreadsheets, scripts, or third-party apps for this process?

I'm part of the development and marketing team behind Field Review for Jira, a Jira Cloud app designed to help administrators review custom-field ownership, purpose, criticality, lifecycle status, review history, configuration context, and governance signals.

We're trying to understand the real challenges Jira admins face and what would make this process easier. I'd genuinely appreciate your experience, suggestions, and feedback.

If you'd like to see what we're working on, here's the app:

https://marketplace.atlassian.com/apps/3892667460/field-review-for-jira

Thanks in advance for sharing your thoughts!

Accepted answers

All comments

Matthew Sinclair

I'll give feedback - but I'm going to be "that admin" and say if you have to pay for an app to do this - you're in deeeep trouble.

But then again - perhaps there are folks drowning in fields? 🤣(I jest - and our org has a mess of our own to deal with)

How do you currently audit and organize custom fields in Jira?

We check the last used date marker - and the spaces its attached too - JQL up a ticket list. I suspect at some point we're going to generally warn our stakeholders "anything not touched in 3-6 months - gets nuked" - obviously data is a concern - but we're a little tired of fields being added and not used.

When new fields get asked - we say "no" - then suggest alternate fields already in system. If its JSM - we push back harder - and let them add them to Custom forms.

New Fields generally are increasingly becoming less and less so when folks realize they don't need fields - they just need better processes.

Do you track field ownership, business purpose, and review history?

We ask these questions as part of a justification process for new fields. Only 1 in 10 makes it past the "firewall" in terms of being added as they already know we generally deny requests these days with all the fields already in system. (5000 Jira spaces and counting in one site - 15-20 sites large org wise)

How do you identify fields with similar names that might serve overlapping purposes?

Same Name - it gets deleted after lifting and shifting data out. Similarly named fields aren't allowed anymore in our org. Field Type mismatches might be an exception - but we've gotten rather aggressive about it these days since guard rails came into effect.

What information do you wish you could see when reviewing a custom field?

Org Administrator override to allow us to JQL data in fields we don't have space permissions with. But that's an inherit design aspect of Atlassian DB's - don't expect it to be granted any time sooner. Also Archived Spaces (Archive - isn't that a rich name for a lie? ha ha ha) won't share any data either - would be nice to be informed of attachments as such.)

Do you use built-in Jira features, spreadsheets, scripts, or third-party apps for this process?

Admin Tools already present - JQL know how - Rovo magic.

We may not be the best use case - but we've really stepped up our game in hammering down.

Thing we purged several thousand fields already - lost count.

Note: This is not an invitation for you to offer us to beta test - just offering feedback/insight - my org won't allow it anyway. Good luck! - Semi-Bitter Org Administrator.

Real MIS

This is genuinely useful feedback — thank you for taking the time to share your experience, especially at that scale!

Your point about better processes reducing the need for new fields really stands out. The fact that only around 1 in 10 requests makes it through your justification process says a lot about the value of strong governance before a field is even created.

I also appreciate your distinction between similar names and genuinely overlapping fields, and your point about archived spaces and visibility limitations. Those are important operational details.

Field Review is intended to help with governance visibility and review tracking, not replace the admin tools, JQL expertise, or strict processes that experienced teams like yours already have. Your feedback is a good reminder that a tool needs to provide value beyond what a disciplined admin team can already accomplish.

And understood on the beta testing point — I'm not asking you to test anything. Thanks again for sharing such a candid, real-world perspective!

Robert Hiles

One practice that helped our team a lot was running a quarterly field review: we pull a list of custom fields, flag any that have not been updated in six months, and check with the owning team before deciding to keep or retire them. We also require a short business justification in the field description for every new field request, which cut down new-field sprawl noticeably. For duplicates, comparing field contexts (which projects and issue types use them) before merging is the step most people skip.

Real MIS

Thanks for sharing this! The quarterly review combined with checking with the owning team before retiring a field sounds like a practical way to balance cleanup with avoiding accidental data or workflow issues.

I especially like the idea of requiring a business justification in the field description when a new field is requested. Preventing unnecessary fields from being created in the first place seems just as important as reviewing existing ones.

Your point about comparing field contexts before merging duplicates is also a great one — similar names alone don't necessarily mean two fields serve the same purpose.

One question: when you flag fields that haven't been updated in six months, how do you distinguish fields that are genuinely no longer needed from fields that are still important but used infrequently?

Arkadiusz Wroblewski

Hello @Real MIS

From what I've seen, the tough part isn't just finding unused fields; it’s figuring out whether it’s actually safe to remove them.

A field might sit untouched for ages but could still play a role in automation rules, workflows, dashboards, or integrations. It’d be way more helpful to have a clear view of what depends on what and know who’s responsible for each field than to just create another list of fields. 🙂

Best,

Arek🤠🧙‍♂️

Rafael Mendes

Echoing what Arek said — the scary part isn't finding unused fields, it's deleting one that turns out to be feeding an automation rule or dashboard someone set up two years ago. Learned that one the hard way 😅

What helped us most: every new field now needs a one-line business justification in its description, and before anything gets retired we check screens, automations, and dashboards that reference it. Sounds obvious, but it killed most of our duplicates.

Real MIS

Thanks, Arek! 🤝 I completely agree — identifying fields that need attention is only one part of the problem. Understanding their dependencies and ownership is what makes the review process more useful.

That's also why we designed Field Review for Jira around governance information such as ownership, business purpose, lifecycle status, review history, and configuration context, rather than treating missing usage data as proof that a field is unused.

Your point about automation rules, workflows, dashboards, and integrations is particularly important. Those dependencies can make the decision much more complicated than a simple field inventory suggests.

Really appreciate you highlighting this distinction. It's useful feedback as we continue improving the app!

Real MIS

That’s a great point 😅 A field can look inactive but still be quietly supporting an automation or dashboard that someone depends on.

I really like the one-line business justification requirement. Preventing unnecessary fields at creation seems much easier than trying to untangle their dependencies years later.

When you check screens, automations, and dashboards before retiring a field, do you have a repeatable checklist or is it mostly a manual investigation by the admin team?

Thanks for sharing what’s worked for you!

Hullspark

Hi @Real MIS , I'll answer from the admin side, using your five questions as the outline.

1. Auditing with built-in tools

Fields are under Settings (gear) > Work items > Fields. Start with the same name used twice, and fields nobody created on purpose.
Know the limit: since March 2026, Jira Cloud allows 700 fields per space, counted from the field configuration schemes the space uses. Deleted fields don't count. https://support.atlassian.com/jira-cloud-administration/docs/data-limits-and-guardrails/
For each candidate, check its screens and its contexts (which spaces and work types). A field on no screen, or whose context matches no space, is the first one to look at.
Then check what reads it. Saved filters, board filters and most dashboard gadgets use JQL, so search your filters for the field name and for cf[ID]. Automation rules and workflow conditions, validators and post functions are not visible from the field page, so check those by hand.
Delete in two steps. A deleted field moves to the Deleted fields tab and is removed for good after 60 days; until then you can restore it with its data. One catch: Atlassian says that once a field is deleted it is removed from any automations, advanced workflow functions and apps that use it, so do the automation and workflow check before you delete, not after. https://support.atlassian.com/jira-cloud-administration/docs/delete-or-restore-a-field/

2. Ownership, purpose, review history

As far as I know there is no owner attribute on a custom field, so the description is the usual place. One line is enough: "Owner: team X. Purpose: ... Added: 2026-03. Review: 2027-03." Keep it short, because the description can also show under the field on screens. Making it part of the request process is the cheapest governance step, as Matthew, Robert and Rafael said.

3. Fields with similar names

Sort the list by name. Before merging two fields, compare their types and contexts (Robert's point): two fields with the same name can hold different types and options, so a rename is not a merge.

4. What I wish the field page showed

A per-space count against the 700 limit, and the saved filters, boards, dashboards and screens that mention the field, in one place. Today those are separate searches.

5. Built-in vs apps

With fewer than about 100 custom fields, I'd do the first pass by hand. Above that it gets slow, mostly because of the "what reads it" step.

Disclosure: I'm with Hullspark and build Field Sweep, a Forge app for that step. Its scans only read: it checks saved filters (JQL), boards, dashboards and screens, and sorts each custom field into "can be cleaned up / to review / nothing found". It can also move fields to Jira's trash and restore them (up to 25 at a time, after a dry run you confirm). It cannot see automation rules, workflows, unshared dashboards or swimlanes, so the manual check above still applies. Free for up to 10 users: https://marketplace.atlassian.com/apps/439033528

Whichever way you do it, the quarterly review with the owning team (as Robert described) is what keeps the number down.

Real MIS

Thanks for such a detailed response! This is one of the most practical explanations of the field-audit process we've received.

Your point about checking what reads a field before deleting it is especially important. Reviewing contexts and screens is only part of the picture; saved filters, dashboards, automations, and workflow functions can introduce dependencies that aren't obvious from the field configuration itself.

I also appreciate your point about ownership and purpose in the field description. Establishing that information when a field is created seems much easier than trying to reconstruct its history during a cleanup.

It's helpful to understand where a dedicated scanning tool can save time and where manual checks are still necessary. Field Review for Jira currently focuses on governance metadata, review history, configuration context, and lifecycle signals, rather than claiming comprehensive dependency detection.

Thanks again for sharing both your process and the limitations you've encountered. This gives us a clearer picture of what Jira admins need from field-governance tools.

Hullspark

Thanks, glad it was useful. One detail I left out that matters for the "what reads this field" step:

Before deleting, it is worth exporting the field's current values for the work items that still have one (JQL: "Field name" is not EMPTY, then export to CSV). The trash keeps the field and its data for 60 days, but once those 60 days pass the values are gone, and a CSV is the cheapest record if someone asks about it at year-end reporting.

And for fields that came over from a migration, check for a near-duplicate with the same name before anything else; merging those first usually removes more fields than the unused-field sweep does.

Hullspark (I build Jira and Confluence admin apps)

Welcome!

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

Quick Links

Find more posts tagged with

atlassian-marketplace

jira-cloud

jira-administration

custom-fields

best-practices