Renaming a field value: what should I do?

Question

Hi everyone,

I need some information. I have a State field of type Select List (single choice) that contains several values.

This field — and its values — is used in automations, filters, and appears on various screens across multiple projects.

I need to rename one of the values from StateIn to StateStart, and I would like to understand whether this change is automatically applied everywhere the value is used, or if I will need to update all references manually.

Additionally, is there a way to extract a list of the automations, filters, or configurations where this field (or one of its values) is being used?

Finally, what would you recommend doing in these situations to avoid any unexpected impact or issues?

Thanks

mir_contact_stable_point_io · Answer

Hi @FrancoB,

This is a very good question because field value changes in Jira often behave differently depending on where the value is used.

1. What happens when you rename a select list value

* The value is updated on existing issues automatically

* However, references to the old value are NOT always updated everywhere

So you typically get a mixed behavior:

* Issues → updated

* JQL filters → may break if they use the exact string

* Automation rules → often still reference the old value and can fail silently or show as invalid depending on the rule type

2. What you should consider before changing it

To avoid surprises, the safest approach is:

* Search for the value in JQL filters (status = "StateIn" style usage)

* Review automation rules (especially conditions and JQL-based components)

* Check dashboards / gadgets that might rely on filters using that value

* If the value is critical, consider adding the new value first, migrating usage, then retiring the old one

Unfortunately, Jira does not provide a perfect built-in way to list every usage of a field value across all configurations, which is why these changes require caution.

In larger Jira environments, this kind of change becomes risky because of hidden dependencies across workflows, filters, automations, and integrations.

This is exactly where having visibility on configuration dependencies helps a lot — before making the change.

Tools like Impact Analysis for Jira can help identify where a field or configuration element is used (workflows, filters, automations, etc.), so teams can understand the impact before modifying values.

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

Dang Quang_ymujlx · Answer

Hi Franco,

From my experience, changing a field name can break multiple components and often requires manual fixes. Some of the issues I’ve encountered include:

Automation rules : Various automation actions such as Edit issue or Field value changed triggers may break if they reference the old field name, and they will appear as if the field has been deleted.

Filters : Any filters using the field in JQL will fail and must be manually updated.

Workflows : These may also be affected, based on what I’ve seen in past changes.

There are likely additional areas where the field might be referenced such as permissions, issue security schemes, and dashboards though I haven’t tested these thoroughly.

As far as I know, there’s currently no tool that provides a detailed map of field usage. It may require custom scripting to gather that information. I really hope the Atlassian Analytics team will eventually expose more data in the product, as that would make it much easier to visualise where fields are used and how they’re configured.

Appreciate if you can share your experiences.

Christopher Yen · Answer

Just tested some of this out in my sandbox,

If you edit the value, what I observed was that the value on the work items updated to the new value but in automations the filter conditions using the old value did not update to the new value. For filters it also did not update and will actually throw an error saying the value does not exist.

As far as I know I'm not really sure if there is a way to extract a list to determine the impact. Sometimes instead of updating a value I will only deactivate it and add the new value separately and update any automations or filters that may depend on it, this way I believe filters that are missed with the old value will not break but with this when reporting you'll have to deal with two different values that may need to be combined in your queries.