Allow minimum and maximum aggregation for date fields
Currently, when adding a date field as a value in a pivot table, the only option is the # of years/# of days/etc. We need the option to add a minimum and/or maximum date for the selected rows. The current 'work around' for this is to create an integer date, and then use a script to format the integer to present as a date. However, when exporting the data, the date shows as the integer value in the exported data, which is an unacceptable result. Adding the date as a row value solves the export issue, but displays all date values for the lowest level of detail in the data source, which is also an unacceptable result. If it was possible to add the minimum or maximum of a date field as a value in the pivot tables, this would solve all of the issues we currently have.
It would be helpful to be able to filter by comparing 2 objects in the data model
Being able to filter a widget or dashboard based upon 2 objects returned from the model would allow for targeted results by allowing end consumers, when creating an N:N or 1:N result to return 1:1 results. This would allow for dynamic filtering of results. For example. I may want only those applicants living within the same city as one of my existing office buildings. This could be done by adding another filter option, result object from model. Then the user could select the object. This will enable dynamic filtering based on result sets rather than strictly selected value filtering.Allow changes to be pushed from Private to Shared viewing
This really should already be an option within this feature but the fact that is not is quite maddening. When I am working on my private dashboards, there needs to be a button to push changes from the private view to the shared view to then republish the results. This should already be a feature and know that many of our clients have complained about this feature. Please please make this update sooner rather than later.
Bug: Co-ownership via AD group fails
Details below. I'd like to know: (a) Can we get a fix in a future version of Sisense? (b) Do other users and Sisense tech get the same issue? (c) Any advice other than my workaround? Try the following: 1. Co-Authoring enabled. Sisense version L2025.2.0.510 2. UserU1 from Active Directory (via LDAP). Within Active Directory, UserU1 is a member of GroupG1. Within Sisense, UserU1 has the Admin role (I haven't checked if role matters). 3. UserU1 creates DashboardD1. 4. UserU1 makes the Sisense Sysadmin and GroupG1 co-owners of DashboardD1, and removes themselves from the list of shares. Expected behaviour: This should result in UserU1 still having co-owner access to DashboardD1 because they are a member of GroupG1. Actual behaviour (bug): UserU1 does not see the Private/Shared toggle button. UserU1 does not see the Share/Republish button. UserU1 can edit widgets on the dashboard (as expected). When another user edits and republishes the dashboard, it overwrites UserU1's changes. (Also, a colleague reported a scenario where maybe UserU1's dashboard failed to get the updates when the dashboard was republished except when they manually clicked restore dashboard; if so, that's probably related to this.) So, when you have co-owner access to a dashboard via an AD group, that seems to behave more like "Designer" access, or like you have only the "Private" version of the dashboard and can't toggle to the "Shared" version. Using non-AD group: I tried the same except that I created GroupG1 in Sisense instead of via AD. Co-ownership worked. Workaround: Do not grant co-ownership to AD groups. Either use Sisense groups or grant co-ownership directly to users.
Favorite dashboard
We produce pre-built dashboards for our customers. They can build their own as well. Often, they will start with one of our pre-built dashboards and modify to their needs. Users want a way to "filter out" our pre-built once they have created their own. One mechanism mentioned was the ability to "Favorite" a dashboard and have a new "Favorites" toggle on the Analytics tab.Enhance Usage Model to include segmentation of Email Subscription vs Front-End queries
When analyzing dashboard and widget query performance, I would like to be able to focus on only front-end user queries, or just on email subscriptions, or both. Unfortunately, the source data of the Usage Analytics Model does not contain information that allows us to distinguish whether a dashboard was executed via the Web UI or through a scheduled job. Therefore, we are unable to perform the requested analysis.Make Filtered Measures plugin work like filtered measures when same field on rows and filter
In this scenario we have... the Filtered Measure plug enabled a dashboard with Brand as a filter, set to include only "ABC" a pivot widget with Brand on Rows set to filter as Highlight values for Total Quantity (working as expected) Total Quantity for Brand = "ABC" (working as expected) Total Quantity for @Brand (working as Sisense expects, but not how we'd expect) The "ABC" row is highlighted as being selected in the dashboard filter. As expected per the Active Filters in Widgets Calculation Hierarchy, the [Total Quantity for Brand = "ABC"] value displays the Total Quantity for the Brand "ABC" row on every row, overriding the row-level Brand grouping/filter for every row. Meanwhile, the [Total Quantity for @Brand], which I would expect to filter on "ABC" as per the dashboard filter, fails to override the row level grouping. I would like for the [@Brand] filter to work in exactly the same way as the [Brand = ABC] filter. With that, our clients go easily do cross-over analysis via multi-pass aggregation: For the customers that purchased the Brand on rows, how many also purchased the "ABC" brand. If ECommerce had a Customer ID in it that might look like: SUM ( [Customer ID] , --limited to customers that purchased the Brand of the row IF ( ( [Total Quantity] , [@Brand] ) > 0 , 1 , 0 --count the customers that purchased the selected dashboard filter Brand, "ABC" ) However, per Sisense Support... Filters defined inside a measure (using the Filtered Measure add-on or formula-level filters) are evaluated earlier in the calculation hierarchy and are isolated from the widget row context. This is why your formula-based approach works and produces consistent baseline and overlap results, while relying on the dashboard filter does not. When the same dimension (Brand) is used both on widget rows and as a dashboard filter, the dashboard filter is evaluated in the context of each row. Because of this shared dimensional context, the dashboard filter cannot act as a fixed reference baseline (for example, “ABC”) across all rows.
Support Changing First Day of Week in Live Models
We have multiple customers and models and depending on the customer, they may want the week to be from Sunday-Saturday instead of only from Monday-Sunday. Currently First Day of Week is only a global setting and only applies to elasticubes. Because of this there is no easy workaround to to accomplish this goal with live models and big query. We're currently on version L2025.3.0.397.
