More Control on Dashboard Date Filters

Feature Suggestions
#1

Hi all,

It would be great if you would be able in Holistics to limit Date selection to a set of dates. For example, I have an actual/target dashboard where the numbers only makes sense if you use:

  • last month
  • last 12 weeks
  • last 90 days
  • last 3 months
  • this month to date
  • this year to date

Use cases

  • For dashboards that you want to keep simple, and limits questions from end users
  • Actual/Forecast dashboards
  • For dashboards where you only want to let end-users see completed months, or only see last 30 days
  • Makes dashboard development much easier, because you don’t need to cover all edge cases that are caused by the too flexible default date functionality.
Rolling x days/x weeks
Rolling x days/x weeks
Reusable filters - aka filtergroups
#2

This probably can be solved by this

#3

Hi @anthonytd
Thank you for your reply

However, this feature is specifically focused on limiting the Data Filter options to a predefined set of dates that the business is used to when reporting.
It is connected to your suggestion, but that one does not address this feature request.

#4

The Date Filter of Holistics as is now, is too flexible.
And Dashboards should be simple and easy to browse/filter. And limiting options to end-users is the best road to simplicity!

#5

Hi Abdel,

Thanks for sharing your idea here. May I understand if the purpose of limiting the date filter options is to give the data team the ability to

  1. Restrict users from selecting a date range they want, so they can only access the date range options you allow them to do so without being able to select other date range options? That way, you reduce the chance of them accessing date range that are out of your expectations.

  2. Make it convenient for users by first letting them choose from commonly used date range options. And if those predefined options are not what they want, they can still continue using the existing date filter capabilities to filter any date range they want?

#6

Hi Vincent,

Thank you for your reply.

  1. Correct
  2. So the feature is about giving Dashboard developers more control on dashboard level. So I think this feature should be to be able to control for each dashboard seperately what filter options are allowed. This can be achieved by using Filtergroups. Reusable filters - aka filtergroups

Some examples

  • You have an Actual vs Target dashboard. There only full months or ytd/mtd make sense
  • In companies that are used to reporting on a specific date unit, like rolling 30 days or last 4 weeks, you also generally want to let people use the options you provide for a dashboard.
    I saw this one touches Dashboard Views where you can provide multiple views of a dashboard to end-users, such as looking at a dashboard with 30 day rolling periods or 4 weeks rolling period or 7 day rolling etc etc.
  • For some dashboard, you might want to give more flexibility, and yes that should also be an option. The point is that, it is not on all dashboards desirable, even not for user convenience. So this decision should be left to the Analyst to decide whether a dashboard should have access to custom dates or not.

Long story short
A dashboard developer should be able to determine per dashboard if it requires custom dates or a predefined set of filters.
As I explained, using Filtergroups and Dashboard views will make this feature even more useful.

Also this feature would be backwards compatible, as it doesn’t require current users to change their current dashboards. You should be able to look per dashboard if you need to limit end-user filters, but the management should be done centrally (Filtergroups)

1 Like
Query Parameters for Dynamic Dimensions, Measures, and more
Filters as Slicers
#7

Thanks for the detailed elaboration!

Just sharing, the Query Parameters might not be the best solution, however, it can open more use opportunities to manipulate your data, it can even solve partially the filter group problem. Below is how I imagine that it would solve your use case with Query Parameter

In your aml files


query_parameter custom_time_period {
  allowed_value: [
    last_7_days_in_US,
    last_30_days
  ]
}

Model orders {
  query: @sql
    select ...
    where
       {{ #if custom_time_period  = 'last_7_days_in_US' }}
          // ... conditions
       {{ #else #if custom_time_period  = 'last_30_days' }}
          // ... conditions
       {{ #else }}
           // ... conditions
       {{ #endif }}  
}

There will be a Custom Time Period filter on your dashboard that allows users to select either Last 7 days in US or Last 30 days.

1 Like
#8

@anthonytd thank you for your example.

This Query Parameter thing is something with a completely different use case, such as calculating a YTD measure field.

For the controlling dates, this will not be the solution to be honest. Controlling dates is completely different. By using this parameter feature as a solution for this, I would introduce more limitations than features.

Reasons why:

  • A filter is not the same as a parameter
  • A date filter must keep its “Date” type so it compiles in SQL to a date
  • A date will still apply to multiple widgets on a dashboard
  • If you would be working with different dates, your logic in SQL with the parameters would get very complex

This feature I requested is actually very simple:

  • Now
    You have a date field where you can select all dates you want for each dashboard.

Requested
Give the Dashboard Creator the control to choose between:

  • loose dates (as is now)
    OR
  • restricted dates (that are centrally defined)

The query parameter feature is desirable, but I would not use it as a workaround here, it introduces challenges that would overcomplicate what we are trying to achieve.

2 Likes