The Custom Field Zoo: when nobody remembers why a field exists

[Maria Reisinger]

The Custom Field Zoo: when nobody remembers why a field exists

Jira's flexibility is the reason most of us adopted it. A new requirement appears, a new custom field is created, work continues. At team level, that is exactly how it should work.

The trouble starts years later, at platform level: hundreds of fields, unclear ownership, duplicate concepts, and dependencies nobody can fully name.

Here is the uncomfortable part: a Custom Field Zoo is not created by bad decisions. It is created by thousands of reasonable decisions made independently.

Four species show up in almost every mature instance:

1. The Duplicate. Team A creates Customer Impact, Team B creates Business Impact, Team C creates Customer Priority. Are these three concepts or one? Without a shared vocabulary, two dashboards will answer the same business question differently. The data exists. The meaning does not.

2. The Abandoned. Created for a migration, a compliance initiative, a one-off report. The initiative ends, the field stays. And "unused" does not mean "unreferenced": workflows, automation rules, filters and integrations may still depend on it.

3. The Overloaded. A field like Business Requirement that slowly becomes responsible for everything: classification, customer requests, compliance notes, release decisions. The field survives. Its meaning depends on who filled it in.

4. The Invisible Dependency. A field is never just a field. Screens, issue types, automations, external integrations. The question before deleting is never "can we remove this?" but "what changes if we do?"

What seems to work in organizations that handle this well:

• Govern the lifecycle, not just creation. Most approval processes end at "field approved". A sustainable one covers Create → Use → Review → Archive, with ownership and review criteria per field.
• Measure usage, not existence. How many projects use the field, how many issues carry values, when was it last updated, what references it.
• Build a shared vocabulary. Before creating a field, ask whether the concept already exists under another name. Many custom fields are terminology problems, not technical ones.

Curious how others handle this:

Do you have a review or archive process for custom fields, or only an approval process for new ones? And how do you find out what actually depends on a field before you touch it?

Full disclosure: I'm co-founder of MetaFrazo, a Marketplace app that surfaces field usage and configuration patterns in Jira. This post is about the governance problem itself, which exists with or without tooling.

[Luke Gackle]

Also interested to know how organisations handle it when two departments want a field for the same thing but want different options for that field to each other 😅

[Shawn Mathias]

If I understand this correctly, there is a way to create context based fields so that the same field name can be used with different options.

[Maria Reisinger]

Great question, @Luke Gackle . And @Shawn Mathias is right. This is technically solvable with field contexts: same field, different option sets per project or issue type.

But that's exactly where the governance question starts. Contexts solve the configuration problem and quietly create a semantic one: the same field name now means slightly different things depending on where you are. A cross-project dashboard on that field looks unified but isn't. You're aggregating apples and oranges under one label.

So before splitting into contexts, I'd ask: do these two departments actually mean the same concept with different granularity (→ contexts are fine), or two different concepts that happen to share a name (→ two fields, clearly named, is more honest)?

The second case seems to be more common than people think.  The conflict about options is often the first visible symptom that the shared vocabulary was never really shared. 😅

How did it play out in your case? Did they end up sharing the field?

[S Fong]

we also face this and we also tell the team to give us the definition for us to input as helptext which we can control via field configuraton scheme.  Hopefully this helps the (2) or more teams agree to use the same field with a slight different meaning, along with the context of the drop-down choices.

[Peter Norris]

There is definitely a need for governance over custom fields. At the moment it is left to us to track these in Confluence, IMHO. We do need to be careful that we don't reproduce information that is already available, and only store the additional metadata about the field (e.g. nominal "owner"). You could store all this in the description but it's not reportable or helpful in an internal review.

[Maria Reisinger]

Thanks @Peter Norris , that describes the pattern really well: the governance layer ends up living in Confluence, maintained by hand, and slowly drifting away from what's actually in Jira.

Your point about not duplicating information is important. The moment you copy field facts (screens, projects, usage) into a page, you own a second source of truth that decays. What Confluence is good for is exactly what Jira has no home for: ownership, purpose, review date, archive criteria.

And the gap you describe is real: you could store it in the description, but the description field was never designed as a metadata store, so anything you put there is invisible to filters and reviews.

[Peter Norris]

Just a few extra fields to store this metadata would be a great addition...

[Otilija]

Our environment in Jira up until 2-3 years ago had no actual Administrator to maintain it or follow any good practices. I started doing a review and audit process where I exported all of our custom fields, and started to mark what potential action we can take (delete, consolidate, keep, needs further review).

Some fields are clearly unused, and can be removed. Some are still being used, and don't have any duplicates, so they can be kept. Some are clearly named almost exactly the same, and should be consolidated whilst different contextst are used (if necessary). Some are a bit more complex, and require a deeper analysis at times. We then simply inform all of the impacted project owners "hey, here's what's happening in 30 days. Let us know if you have questions." You then require a standard framework, and providing users with alternative options when they ask for a new field that basically means the same thing as 20 other fields you own.

We can now see when fields are used via filters and spaces. You can also see the context of the fields via REST API to determine if it's part of a third-party app. It can be difficult to find it elsewhere, that's why it's good to give users a notice period for them to inform you. And if something does break, it's fine, because you have 60 days to restore it - that's 60 days for someone to notice it.

To address the overall problem, you probably need to:

1. Align with stakeholders - Actually get stakeholders who use Jira on a daily basis on board with consolidating all your custom fields and adopting a standardized framework accross the organization
2. Develop a standard framework - Review what projects are using, create a standard framework to use accross the organization - customization should still be allowed, but alot of the time, they're using fields where they shouldn't be (not utilizing components, versions, resolutions, statuses, already existing fields, etc.)
3. Roll out standard framework - Roll out the standard framework you developed; get rid of the custom fields that no longer serve a purpose and moving forward, have a full approval process and existing custom field review process to determine if something new actually needs to be created

Not only would this plan help clean up custom fields, you can then start to develop standard schemes elsewhere, which will cut down on extra/unecessary objects there aswell.

[Maria Reisinger]

Thanks for sharing your process. Starting with classifying fields instead of immediately deleting them makes a lot of sense. "Delete, consolidate, keep, needs further review" feels much more realistic than trying to clean everything up in one go.

I completely agree that stakeholder alignment is essential. Technical analysis tells us what can be changed, but the business ultimately decides what should be changed.

The 60 day recovery window is a good safety net, but it doesn't replace understanding dependencies beforehand. If an automation quietly breaks and nobody notices for weeks, restoring the field is only part of the solution.

I also like how your approach naturally extends beyond custom fields. Once governance exists for one configuration object, it often becomes the foundation for governing workflows, schemes and the rest of the Jira configuration as well.

[Barbara Márkus]

What I genuinely miss is the ability to archive. There is nothing in between active and deleted. How do we mark fields that are no longer to be used. We don't want to delete them yet we want to indicate that it shouldn't be used anymore. I'm wondering what solution is there for this on the roadmap?

[Maria Reisinger]

That's a great point. Right now, Jira essentially offers two states for custom fields: active or deleted. There isn't really a lifecycle state like "retired" or "do not use."

Many teams work around this by renaming fields to something like [Deprecated] Customer Impact or ZZ_Do_Not_Use_Customer_Impact, removing them from screens, and documenting that they shouldn't be used for new work. It works, but it's a convention rather than actual lifecycle management.

Ideally, there would be a transition state where existing data remains available, while everyone knows the field is no longer meant for new issues.

I'd be very interested to see whether something like field lifecycle states is on Atlassian's roadmap. It feels like a natural complement to approval and governance processes.

[S Fong]

Another confusion is when people adds fields to the columns on Filters.  This may gives them an incorrect perception on the space because many of these fields may not be used on the space that the user is looking for.  Wonder if we can limit the user to add field column only to the space on filter that the field is actually on the screen.    

[Davit Mkrtchyan - Be On Time]

 Hi Maria and everyone -

This is a fantastic deep dive. The discussion about "retired" states and the "deprecated" naming convention really hits home - it is the classic way we all try to manage the chaos.

I would like to throw in a perspective on the root cause. Why do these "zoos" grow so aggressively in the first place?

In my experience, custom field sprawl is often a symptom of a Resource Management problem in disguise.

Many organizations try to force Jira to do things it was not natively designed for - like tracking resource capacity, allocation percentages, or project cost rates. They create a field for "Allocation %" or "Resource Level" because they are trying to turn a task tracker into a professional governance system.

The real "cleaning" of the zoo usually does not happen by deleting fields or refining the approval process. It happens when the organization realizes that a task tracker is not a resource engine.

When you move the resource and capacity layer into a dedicated professional tool, dozens of those "strange" and "overloaded" fields simply become unnecessary. You do not just clean the fields - you remove the need for them to exist.

It is a shift from "cleaning the zoo" to "changing the habitat." Once the governance is handled at the right level, the Jira instance naturally becomes leaner and faster.

Looking forward to hearing if others have seen this pattern where fields were just a proxy for missing resource visibility!

---

[Maria Reisinger]

Thanks, Davit. I think that's an interesting perspective, especially for organizations that use Jira for resource management.

At the same time, I see it a little differently. For many organizations, Jira has evolved far beyond being just a task tracker. It's where work actually happens. That's one of the reasons I find it valuable when governance is embedded into the place where work happens, rather than becoming a separate activity afterwards.

One of Jira's biggest strengths is that it already captures so much information as part of everyday work. To me, it feels like a missed opportunity if we don't use that to support governance as well. The goal isn't to make governance another process people have to follow. It's to make good governance the natural outcome of the way people already work.

Of course, specialized tools have their place. But even then, questions like ownership, shared terminology, lifecycle and dependencies still exist. Those conversations don't disappear just because some data moves into another system.

So I'd see resource management as one possible contributor, but not necessarily the root cause.

[Julien Morel]

This is exactly why I like keeping a tiny field register outside the field configuration itself. Nothing fancy: field name, purpose, owner, projects using it, reporting dependency, and a review date.

The review date is the part that makes the difference for me. Without it, the field has an owner only on the day it is created. Six months later, nobody feels responsible for deciding whether it is still needed.