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.Extending pivot widget panel limits in Sisense using user groups
Overview Pivot widgets in Sisense are often used to explore and visualize complex datasets with multiple dimensions and measures. In some scenarios, users need to build very large pivot tables with many rows, columns, values, or filters. However, pivot widgets enforce internal panel item limits that can restrict how many fields and dimensions can be added to each panel. While these limits are useful for protecting performance, load time, and usability in general, they can become a constraint for advanced users working with large datasets or detailed analytical models. At the same time, organizations may want to apply different limits for different groups of users rather than increasing limits globally for everyone. This use case describes a Sisense plugin that automatically increases pivot panel limits as widgets load, with support for both a global default and optional overrides based on user group membership. The challenge By default, pivot widgets in Sisense can reach panel item limits that prevent users from adding additional dimensions or measures. This can affect: Analysts building large exploratory pivot tables Power users working with wide schemas or detailed hierarchies Dashboards that rely on complex pivots with many fields Manually adjusting widget configuration is not scalable, especially when dashboards contain many pivot widgets or when widgets are opened independently outside a dashboard. In addition, organizations often want different limits for different user groups, rather than applying a single global setting. It is important to note that if a very large number of dimensions are used in an individual pivot widget, that widget may have an extended load time. What the solution does The PivotMaxPanelItems plugin automatically sets the panel.metadata.maxitems value for every panel in pivot-type widgets as they load. At a high level, the plugin: Applies only to pivot widgets Updates all pivot panels (rows, columns, values, filters) Works for widgets inside dashboards and for widgets opened directly Supports a configurable default limit for all users Supports optional overrides based on Sisense user group membership The plugin runs on dashboard and widget load events, ensuring that pivot panel limits are applied consistently without requiring manual changes to individual widgets. Role and group-based configuration The plugin can apply different panel limits depending on the user’s Sisense group membership. This allows organizations to: Grant higher limits to advanced users or analysts Keep more conservative limits for general users Control behavior centrally through configuration If a user belongs to multiple configured groups, the plugin applies the first matching group based on the order defined in the configuration file. If no group matches, the default limit is used. This approach provides flexibility while keeping behavior predictable and easy to manage. How it is used Configuration is handled through a simple configuration file included with the plugin. Administrators can define: A default maximum number of items per pivot panel Optional overrides for specific Sisense user groups Once configured and installed, the plugin will likely require minimal ongoing maintenance in most circumstances. It applies automatically whenever pivot widgets are initialized. The full plugin is attached as a Zip file to this article and is available to download. The code is not compressed or obfuscated, and can be modified as needed, or used as example code for similar plugins. The plugin can be installed as a standard plugin by placing the decompressed folder into the plugin folder. The plugin includes a Readme file with further information. Why it’s useful This approach allows organizations to remove artificial constraints on pivot widget design while still maintaining control over performance and usability. Key benefits include: Enabling larger and more flexible pivot tables Reducing manual widget configuration and rework Applying consistent behavior across dashboards and standalone widgets Supporting different usage patterns across user groups Centralized control through a single configuration file The solution is particularly valuable in environments where advanced users need more flexibility without changing defaults for all users. Outcome With the PivotMaxPanelItems plugin in place, pivot widgets can support more dimensions without manually adding widget scripts. Advanced users gain the flexibility they need, while administrators retain control over limits at the group level through simple configuration. By applying limits automatically and consistently at load time, the plugin ensures predictable behavior across dashboards and widgets, supporting scalable group and role-aware analytics and visualization in Sisense. Screenshots Without a plugin, if a panel type includes too many items, the Add Panel Button is hidden With the plugin, the Add Button does not disappear when below the new limit, as many dimensions and fields as needed can be added to the widget.
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.
