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.