Cascading filters in UI Builder

[ShivamKumaD8593]

Are Cascading filters not yet available on the Workspace environment.

[Itallo Brandão]

Hi @ShivamKumaD8593 ,

Short Answer: If you are looking for a simple "Cascading" checkbox like in Classic Dashboards, no, it is not available yet in that specific simplified form.

Long Answer (How to achieve it): In UI Builder (Workspace), "Cascading" behavior is not a widget setting; it is a Data Dependency configuration that you must build manually using State Parameters.

You can achieve the exact same behavior by linking the filters sequentially:

The Logic: Filter A (Select) -> Updates @State -> Filter B (Data Source reads @State)

Step-by-Step Implementation:

1. Create a State Parameter: Create a parameter to hold the first value (e.g., selected_country).

2. Configure Filter A (Parent):

   • Set its event handler to "Update Client State Parameter".

   • Target: selected_country.

   • Value: @payload.value.

3. Configure Filter B (Child):

   • Go to the Data Resource that feeds this filter (e.g., "Look Up Records").

   • Edit the Encoded Query or Condition to depend on the state.

   • Example: country = @state.selected_country.

   • Important: Set the Data Resource to "Evaluate when input changes" (if applicable) or ensure the filter component re-renders when the state changes.

Result: When the user picks a Country in Filter A, the State updates, which triggers Filter B's data source to refresh, loading only the relevant States/Cities.

Is this Best Practice? Yes, in the UI Builder paradigm, explicit state management is the standard way to handle component dependencies, rather than implicit widget behavior.

If this clarifies the "How-To" for Workspace, please mark it as Accepted Solution.

Best regards,
Brandão.

[ShivamKumaD8593]

But why its working for incident table when I am using caller and Assignment group in this both are cascaded each other why?

[Itallo Brandão]

Hi Shivam,

That is an excellent observation!

The reason it works automatically for Caller and Assignment Group in your scenario is likely because of Data Faceting (filtering based on results), not explicit cascading configuration.

Here is the technical difference:

1. Why it works for you (Facet/Data Source Filtering): If both of your filters are connected to the same Data Source (e.g., the Incident List), they act like Facets.

• How it works: When you select a Caller, the Data Source updates and returns only the records for that user (let's say 5 incidents).

• The Assignment Group filter then looks at those 5 remaining records and updates itself to show only the groups present in those specific records.

• Conclusion: It "cascades" because the data result set got smaller, so the available options were reduced automatically.

2. When you need the "Manual State" method: The method I described in my previous reply is required when you want "Input-Based Cascading" without fetching data first, or for unrelated fields.

• Example: Selecting a Country and then seeing a list of Cities.

• Since "Country" and "City" are just lookup values (not incident records), picking a Country won't filter a list of Incidents instantly. You need the State Parameter to tell the City filter: "Hey, the user picked USA, please only load US Cities from the reference table."

Summary:

• Automatic: Works if filters share the same Data Source and are filtering an existing list of records (Facet behavior).

• Manual (State): Required for Reference Inputs, standalone dropdowns, or when filtering queries before the data is loaded.

If this clarifies the "How-To" for Workspace, please mark it as Accepted Solution.

Best regards,
Brandão.