Currently, there is a workaround to accomplish this desired behavior without needing this parameter to be implemented. You can add a "listing" filter to your KPI (implemented on a widget) and then inside of %OnGetListingSQL, you can assign different SQL based on the filter value.

XData:

<filter name="Listing" valueList="listing1,listing2"/>

%OnGetListingSQL:

if $get(pFilters("Listing"))="listing1" {
set tSQL="SELECT <column list 1> from <table>"
else {
set tSQL="SELECT <column list 2> from <table>"
}

Hi David,

By default, this happens when items are in a hierarchy. For example, if you have Product Category and Product Name as filters and you filter on the Pasta Category, only the Product Names in the Pasta Category will be available to select from. If two levels are not in the same hierarchy but you would like the same behavior, you can use the "Depends On" property of a level. This property can be found on the Architect Management Portal Page in the right side pane after clicking on a level. After setting this property and compiling, a Build will need to be done. This is because using the "Depends On" property will create a new index to quickly determine which members should be displayed when using a filter control.

After this behavior is understood, you may wish to add hidden filters to your widget with default values. For example, I could set Pasta as my Default Value for my hidden Product Category filter. When I try and select a value from my Product Name filter, I only get my different Pasta names as options.