How to implement dependent dropdown fields in Jira (State ↔ City mutual dependency) using Forge?

[Paidipati_ Lokesh]

Hi Team,

Hi everyone,

I’m building a solution in Jira using Forge and need help implementing dependent dropdown fields with two-way dependency.

Use Case

I have two dropdown fields:

• State
  • AP
  • Telangana
• City
  • Hyderabad
  • Secunderabad (for Telangana only)
  • (other cities for AP if applicable)

Expected Behavior

1. When user selects:
   • State = Telangana
   • → City dropdown should show only:
     • Hyderabad
     • Secunderabad
2. When user selects:
   • City = Hyderabad
   • → State should automatically be set to:
     • Telangana

So the dependency should work in both directions (State ↔ City).

I would appreciate any recommended workaround approaches by using Forge.

Thanks,

Lokesh

[Germán Morales _ Hiera]

Hi @Paidipati_ Lokesh , the two-way part is what makes this tricky, so the right approach depends on whether State and City have to be two separate Jira fields or can be one. Both have a clean Forge path.

• Two separate fields with live reactivity on the create and edit screens: use Forge UI modifications, the jira:uiModifications module. It runs client-side on those screens, so you listen for a change on State and filter City's options, and listen for a change on City and set State. That is exactly the cross-field behaviour it exists for. Just confirm your field types and the screens you need sit in its supported list.
• One encapsulated field: a Forge custom field built with Custom UI that stores both values as an object and renders both dropdowns in its own edit view. As a single client-rendered component you drive both directions directly, with no cross-field sync to maintain.

What to avoid here is a plain UI Kit custom field. UI Kit edit views are server-rendered, so a second field won't react when the user changes the first; the live filtering and the back-setting need the client-side route, meaning UI modifications or Custom UI.

If any part can't be live, enforce it after save with a Forge product trigger on issue updated, or a Jira automation rule. For example, setting City to Hyderabad would set State to Telangana. References: UI modifications and Jira custom field type.

[Paidipati_ Lokesh]

Hi @Germán Morales _ Hiera 

Here are the details:

 State - Select List (single choice) custom field

City - Select List (single choice) custom field

Screen

Create Issue screen -Yes (all fields are used here)

[Germán Morales _ Hiera]

Perfect, that settles it. With both as standard single-choice selects on the Create screen, UI modifications handles the whole thing, and the method that makes it click is setOptionsVisibility. In your State field's onChange you call City.setOptionsVisibility to show only the cities that belong to the chosen state, so picking Telangana leaves just Hyderabad and Secunderabad in the City list. In the City field's onChange you go the other way with State.setValue, so picking Hyderabad sets State to Telangana. A useful quirk: an option hidden by setOptionsVisibility can still be applied with setValue, so the back-direction keeps working even while City is filtered.

Two things to keep in mind: setOptionsVisibility takes either a show-these or a hide-these list, not both in one call, which suits your case fine, and you should read the triggering value from the onChange event rather than a getter, because getters return the form's initial state until the batch is applied. It all runs on the create form, so it shapes the UI but won't police values written later through the API, and the methods with their limits are laid out in Atlassian's UI modifications reference.