Do dynamic filter options for dashboard/widgets?
Summary: James Haid is seeking a solution for adjusting sales activity calculations on a dashboard based on various time periods, without relying heavily on storage. The current solution using Elasticube (EC) is storage-intensive. Angelina_QBeeQ suggests introducing a bridge table instead of modifying the fact table. This bridge table would expand time periods into individual rows to connect with the fact table and use filters effectively. The proposed method aims to maintain dashboard efficiency while reducing storage needs.
I'm looking for a solution that adjusts sales activity calculations throughout the dashboard based on the number of days contained within the Time Period (ex. 1 Week, 4 Weeks, 13 Weeks, etc...) selected by a Viewer from a dashboard filter. For example, if the Viewer selects "4 Weeks", then the calculations are performed based on activity during the last 0-27 days. If "13 Weeks" is selected, the calculations are performed for the last 0-90 days. Although this has been solved via the EC, we're curious if there's a dashboard-centric solution because the EC solution is storage intensive due to storing data calculations 8 times (Current, Previous, YA) for each of the time periods that are common in the grocery industry.
Background:
Calendar Date selection can not be used because the underlying data is sourced from multiple 3rd parties who often use different days of the week as the end date for their report periods. Thus, individual customers of ours do have data inputs that end on Saturday, Sunday, and/or Tuesday. This is why we reference days_since_sale, which starts at 0 on the report end date for each data source and increases as you go further back in time, thus normalizing the offset that exists between the report end dates for the different data sources.
Within our EC, we have a table that identifies the start and end values that should be applied to limit days_since_sale for each Time Period option. Each Time Period (time_period) has a cur_start_date value (always 0), cur_end_date value (ex. 27 for "4 Weeks"), along with Previous and YA limit values. This is used in our current EC solution, and can be referenced if a dashboard centric solution exists.
We've tried various approaches, including Filter Measure, without any success. The underlying issue is that widget formula filters don't support dynamic filters if the necessary table.column is not included in the dashboard filters.
The goal of this question is to identify if there are solution(s) that will enable dashboard widgets to support this dynamic filter scenario. A native solution is desired, but we are open to applying custom scripts, etc...
Regards,
Jim
Angelina_QBeeQ
·Sep 17, 2026 at 9:55 AMHi @James Haid
One option worth testing would still involve the Elasticube, but instead of modifying or duplicating the fact table, you could introduce a bridge table.
The bridge table could be generated from the Time Period configuration that already exists in the Elasticube. It would contain one row for each combination of Time Period, comparison type, and days_since_sale.
For example:
4 Weeks | Current | 0
4 Weeks | Current | 1
…
4 Weeks | Current | 27
4 Weeks | Previous | 28
…
13 Weeks | Current | 0
…
13 Weeks | Current | 90
In other words, each configured range would be expanded into individual rows, one row for each days_since_sale value.
The bridge table would be connected to the fact table through days_since_sale. The dashboard would use time_period from the bridge as a required single-select filter, while the widget measures could use comparison_period as a formula filter.
This approach would leave the fact table unchanged. Only the small bridge table would be expanded, which should require significantly less storage than materializing multiple calculated copies of the fact data for every supported period.
The main consideration is:
Because the same days_since_sale value can belong to multiple Time Period definitions, the dashboard should always have exactly one Time Period selected. I would also ensure that each combination of time_period, comparison_period, and days_since_sale is unique and test any widgets that might execute without the Time Period filter.
Always here to help,
Angelina from QBeeQ
angelina.bulgakova@qbeeq.io
QBeeQ - Gold Implementation and Development Partner