Adding or Removing a Field from a Jira Screen Sounds Simple… Until It Isn’t 😅

[#1]

One of the most common Jira admin requests is:

“Can we add this custom field to the screen?”

“Can we remove this field? Nobody uses it anymore.”

At first glance, this looks like a very small configuration change.

But in medium and large Jira environments, screens are often heavily shared across:

• projects

• issue types

• workflows

• screen schemes

• request types

And that’s where things become risky.

A simple field modification can unexpectedly impact:

• multiple teams

• unrelated projects

• automations

• integrations

• validators

• reporting

• portal forms

• API consumers

In many Jira instances, admins don’t always realize:

• which projects share the screen

• where the field is still used

• whether automations depend on it

• if integrations are consuming the field

• how far the change propagates

The real challenge is usually not making the change.

It’s understanding the full impact before making it.

That’s actually one of the reasons why I started building:

🚀 Impact Analysis for Jira

The app helps Jira admins visualize:
✅ Screen dependencies
✅ Shared configurations
✅ Custom field propagation
✅ Workflow relationships
✅ Automation impact
✅ Project key dependencies
✅ Configuration anomalies

So before adding or removing a field from a screen, admins can better understand:

• which projects are impacted

• which issue types are connected

• whether configurations are shared

• what downstream risks exist

Instead of discovering problems after deployment.

👉https://marketplace.atlassian.com/apps/4251492671/impact-analysis-for-jira?hosting=cloud&tab=overview

Curious how other Jira admins manage screen and field impact analysis today in large environments 👀