Acumatica GI Cascading Parameters — Dependent Filters

A parameter that filters "Country" is easy. A parameter that filters "State", where the list of valid states depends on which country was picked one field earlier, is where most GI parameter setups fall apart, because the GI Designer does not give you a first-class "cascading dropdown" widget the way a modern web form framework would. You build the cascade out of selector conditions instead.

Selectors that filter against another parameter

Each GI parameter with a selector-type control (a DAC-backed lookup) can carry its own Conditions, scoped to that selector's underlying data view rather than the GI's main result set. The trick is referencing an earlier parameter's current value inside a later parameter's selector condition:

Parameter 1:  @Country     (selector on Country DAC)
Parameter 2:  @State       (selector on State DAC)
              Condition:  State.CountryID  Equals  =[@Country]

Order matters — parameters evaluate top to bottom on the Parameters tab, and a parameter can only reference parameters declared above it. Acumatica does not auto-refresh the second dropdown's cached list when the first one changes in every build; on some versions the user has to reopen the selector for the filtered list to take effect, which is a real usability wrinkle worth testing before you promise a slick cascading UX to a client.

Cascading into the result set, not just the selector

The more common real requirement is not "filter one dropdown by another" but "use the second parameter to filter the main GI results, with its own valid-value list narrowed by the first". That is two separate mechanisms working together: the selector condition above narrows what the user is offered, and a normal Conditions-tab entry on the main data source narrows what gets returned:

InventoryItem.CountryOfOrigin  Equals  =[@Country]
InventoryItem.StateID          Equals  =[@State]   (only applied if @State is not empty)

For the "only applied if not empty" behavior, use the standard optional-parameter pattern: wrap the condition so an empty parameter effectively matches everything, typically by pairing the equals condition with an IsNull/blank check joined by Or, or by using the built-in "allow blank" semantics the designer offers per condition row depending on version. Test the blank case explicitly — a cascading filter that silently returns zero rows when the second parameter is left empty is the single most common bug report I get on these builds.

When the cascade goes three levels deep

Country → State → City is where I stop trusting the designer's selector conditions alone and instead build a small supporting projection or rely on the Acumatica generic selectors already provided for address-style cascades (Country/State are standard system DACs with this relationship built in). For a genuinely custom three-level business hierarchy — say Region → Territory → Branch on a custom dimension — I put the parent keys directly on the child DAC (denormalized) rather than requiring a chained join at filter time, because chained selector conditions three levels deep get slow to populate interactively and are painful to debug when something in the middle is misconfigured.

Wrapping up

Cascading parameters in GIs are built from two separate pieces — selector conditions that narrow what a dropdown offers, and main Conditions-tab entries that narrow what the query returns — and both need to be wired for a genuinely cascading experience. Keep cascades to two levels where you can, test the empty-parameter path explicitly, and denormalize parent keys onto child DACs when a hierarchy runs three levels deep.