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 * When user selects:* State = Telangana * → City dropdown should show only:* Hyderabad * Secunderabad * 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

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.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

When user selects:
- State = Telangana
- → City dropdown should show only:
  - Hyderabad
  - Secunderabad
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

Accepted answers

Germán Morales

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.

All comments

Germán Morales

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.

Paidipati_ Lokesh

Hi @Germán Morales

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

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.

Paidipati_ Lokesh

Hi @Germán Morales

Thank you for the detailed explanation.
setOptionsVisibility and setValue approach is exactly what we need for State-City requirement.

However we are facing a blocker — onInit and onChange are not firing at all.

Browser console error:
"TypeError: removeOldAnalytics is not a function"in Jira's own batch.js

This is preventing the Forge bridge from initialising.

What we have already done:
- manifest.yml correctly configured with
jira:uiModifications
- UIM entity registered via REST API (got 201)
- @forge/jira-bridge updated to latest (0.40.1)

Could you please suggest a workaround to implement
State-City without relying on jira:uiModifications while we wait for the batch.js issue to be resolved?

Any alternative Forge approach would be helpful.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

forge