Forum Discussion
Unsupported Filter Error with Dynamic M Query Parameter Binding on Visual Selection
- 2 months ago
This looks like a limitation of Dynamic M Query Parameters rather than an issue with Snowflake or the stored procedure itself. Dynamic M parameters are designed to receive values from supported slicers or filter cards, but not every filter generated by report interactions is supported. In this scenario, when you use the parameter-bound columns directly in a visual hierarchy and then drill further down, Power BI can generate a drill-down / multi-field / cross-filter type of filter. Those filter types are not supported for Dynamic M Query Parameters, which explains why the first level may work but the next drill level breaks the report with the “unsupported filter” message.
The more reliable pattern is to separate the two behaviors. Use normal model columns for the interactive waterfall visuals and drill-down experience, and use dedicated parameter tables/slicers or filter cards to drive the Dynamic M parameters that are passed to Snowflake. For example, have separate slicers for Area, Market, TA and Brand, configured as single-select or multi-select according to how the M parameter is defined. Then let the AI Summary/stored procedure respond to those slicer selections, not to visual drill-down selections.
If the requirement is that clicking a waterfall item must directly trigger the stored procedure, then I do not think this is currently a supported native pattern with Dynamic M Query Parameters. Possible alternatives are to precompute the summary at the required grain and filter it normally in Power BI, use slicer-driven cascading selections instead of drill-down, or move the interactive procedure-triggering logic outside the standard Power BI visual interaction model. I would also avoid using parameter-bound columns inside visual hierarchies, because drill-down and cross-filter interactions can easily produce unsupported filters for Dynamic M parameters.
If this post helps, then please consider Accepting it as the solution to help the other members find it more quickly
This looks like a limitation of Dynamic M Query Parameters rather than an issue with Snowflake or the stored procedure itself. Dynamic M parameters are designed to receive values from supported slicers or filter cards, but not every filter generated by report interactions is supported. In this scenario, when you use the parameter-bound columns directly in a visual hierarchy and then drill further down, Power BI can generate a drill-down / multi-field / cross-filter type of filter. Those filter types are not supported for Dynamic M Query Parameters, which explains why the first level may work but the next drill level breaks the report with the “unsupported filter” message.
The more reliable pattern is to separate the two behaviors. Use normal model columns for the interactive waterfall visuals and drill-down experience, and use dedicated parameter tables/slicers or filter cards to drive the Dynamic M parameters that are passed to Snowflake. For example, have separate slicers for Area, Market, TA and Brand, configured as single-select or multi-select according to how the M parameter is defined. Then let the AI Summary/stored procedure respond to those slicer selections, not to visual drill-down selections.
If the requirement is that clicking a waterfall item must directly trigger the stored procedure, then I do not think this is currently a supported native pattern with Dynamic M Query Parameters. Possible alternatives are to precompute the summary at the required grain and filter it normally in Power BI, use slicer-driven cascading selections instead of drill-down, or move the interactive procedure-triggering logic outside the standard Power BI visual interaction model. I would also avoid using parameter-bound columns inside visual hierarchies, because drill-down and cross-filter interactions can easily produce unsupported filters for Dynamic M parameters.
If this post helps, then please consider Accepting it as the solution to help the other members find it more quickly