Make Dashboard Import in Linux as good as it was in Windows, or better.

wallingfordce · ‎03-12-2025

We are OEM with several hundred client organizations, each of whom have their own set of our standard data models. The data sources are prefixed with a client code so that the same data model can be distinguished and secured between clients. Have two sets of the same data models with different data. Have two users, each with access to only one of the two sets of data models. One user creates a dashboard that uses multiple data sources. The dashboard is export to .dash file and shared to the other user who imports it. The second user then needs to update the dashboard data sources to see the dashboard render with their data. Importing that dashboard into Windows and updating the data sources: 2DSDashImportWindows.mp4 Just update the data sources at the dashboard level. Importing that dashboard into Linux and updating the data sources: 2DSDashImportLinux.mp4 Update one data source at the dashboard level. Then update each widget in the dashboard to use that data source. Then update the other data source at the dashboard level. Then update each widget in the dashboard to use that data source. How many widgets in your dashboards 😉

adam_chapman · ‎03-20-2025

Hello, We recently had an AI demo meeting where we were shown some of the AI capabilities of Sisense. However, the LLM providers that are currently being supported do not align with the AWS eco system we are currently using in house. Would it be possible to support AWS Bedrock as an LLM provider? At the moment this is the only road block on our end from trying your LLM supported AI features within Sisense.

ccoelho · ‎03-17-2025

To filter any data we need to add the filter on the right panel. Though this is possible only for a desinger and if a viewer wants to filter any other columns in the widget after the result set is displayed, they will need to download the table and filter in csv/excel. It will be really nice to be able to further filter the result set by viewer after the data is processed/displayed by having this option visible on every column header. Currently, clicking the column header only sorts the data, keeping a filter option on every column can allow the user to narrow down the results before downloading the file. Using this option, the viewers can filter any of their columns in table widget without having the need to download and analyze the results outside sisense.

ni-rwhite · ‎03-19-2025

The UI limits the number of recently used drill-in fields to 5. I've attempted to write custom JavaScript to add additional entries to widget.metadata.drillHistory, and verified they are added to the array successfully, however the UI will only show 5 drill-in values. This is important because our customers need to be able to "slice and dice" data visually and the best way to do that on a single chart is by using drill-ins. We do not want customers to have to "Choose another" because nearly all of these customers are viewers and do not have or need extensive knowledge of the data model. Having an option to increase this, either as a dashboard JavaScript override, or as a feature in the configuration of the product itself would be very beneficial.

alisonhenley · ‎03-14-2025

Unsure if it has to do with the numerous columns that we have in this table specifically but there is no drag scrollbar to be able to see beyond the first 6 columns. It would be nice to enable scrolling despite numerous columns so that users do not have to manually download the report.

ccoelho · ‎03-10-2025

While downloading a large csv/excel file (over several hundreds mb file) from the widget, there would be a long delay of couple minutes before the browser indicates the file has been downloaded. During this time, the user has no indication if the request to download is in process or has failed. It would be good to have an indicator to show the download of the file is in progress, so user would not click the download multiple times thus causing multiple queries to hit the backend.

cjakerle · ‎03-09-2025

In addition to not being able type in dates with the Calendar item in the date filter (I submitted that as a separate idea to be able to type in dates), the general date selecting user experience is quite cumbersome. It's hard to write this out and much easier to show. But the short story is that it is difficult to select the dates on the first try. A pretty typical interaction with the calendar component goes something like this: Open the filter Select Calendar Pick the start date Perform however many clicks it takes to get to the date you need (sometimes this can take a few clicks if you are going back a few years/months) At this point you think you have selected the start date Now, move your cursor to go select the end date At this point, the start date loses your initial selection. I think this happens 90% of the time Sometimes the issue is that the start date gets set to the new end date Sometimes it resets before you even get to the start date Sometimes it goes back "Select" like you never picked a date This behavior is quite frustrating. I have experienced it quite a bit myself and customers have complained. I hope there is something that can be done to improve it.

ccoelho · ‎03-17-2025

The page controls to change the pages are currently within the widget and its functionality is limited: Thus, if the number of rows to be displayed are increased to 50 or so, the widget window would get expanded and user will have to scroll to the bottom of the dashboard to see the page controls or change the widget page. This can be avoided by placing the page controls at the bottom of the widget window and not limiting it to the size of rows. So the widget window size stays fixed and the user can scroll through the data within the table widget. This also helps view the dashboard in the page without having the need to scroll down at the bottom of the dashboard. Additionally, also allow the viewer to increase the number of rows to be viewed in the widget. Example, a user should be able to increase the number of rows for a table widget to fixed numbers as 50 or 100.

lsher1 · ‎03-11-2025

I have previously worked with Periscope and found the SQL Snippets tool to be very helpful (https://dtdocs.sisense.com/article/snippets#:~:text=To%20create%20a%20SQL%20snippet,button%20and%20name%20the%20snippet.&text=Snippets%20with%20these%20characters%20included,the%20box%20and%20click%20save.) Now my team use Sisense Fusion and we still have a need for this tool, despite it not being a feature in Fusion. We hope to have it available in the future.

fredshepper · ‎03-11-2025

Regex is of course supported when querying through the import MySQL query, but custom Sisense tables do not support regular expressions. It would be useful to have regex functionality in custom tables and custom columns as well.

toneill · ‎02-07-2025

For the pods that sisense deploys into the kubernets cluster (bld and qry pods) being able to customize these specs would be helpful to get true node isolation and for log shipping. Currently we can set the Limits and Requests for these pods. It would be nice if there were a configuration setting that would allow us to add a toleration to the spec so our cluster can use taints. Also adding custom annotations to these pods would allow us to ship the logs to our log management system giving us greater insight and monitoring.

bmorse · ‎02-04-2025

When adding a new piece of data to a widget, instead of having to add one at a time, add a checkbox to each item to the left of each item in the list. The user can check the box for each item they want to add to the widget, instead of having to add one at a time. This will speed up adding many items to a widget.

lucycheng-8451 · ‎02-21-2025

It is currently possible to add a second axis, but we would like to expand this capability to have more axes on a chart or line chart with Compose SDK. Data visualizations are becoming more advanced and to match our competitors, we would like to have this capability to build a chart where users can select and display multiple measures on one chart. For our future dashboard, we plan to have a longer list of KPI measures that users can select from to ensure a customizable and interactive experience.

betapure · ‎03-04-2025

Current State: As of now Sisense supports adding of pulse alerts only for select chart types, like, Indicator, Area, Line, Bar and Column. Expected State: Sisense shall allow rest of the chart types as well to add pulse alerts. It is observed in other competitive products to be available for all the chart types. Customers like us (Blackline) have many use cases of tabular widgets and end users expect alert to be added to these widget types.

sam_detzler · ‎12-24-2024

Managing pulse alerts is a nightmare, and is in dire need of improvement: 1 It's impossible to identify who added you to an alert, and there's no way to unsubscribe, so you can't manage them from the recipient side. 2. Tenant or system admins can't see all pulse alerts configured, so they have no way to identify troublesome alerts. 3. The current supported APIs don't allow identification of other's alerts. The alerts API only returns the user's alerts, and the "recent" alerts API doesn't return the ID of the alerts so you can't just delete the troublesome ones. There needs to be some attention spent on alerts, as they are currently a nuisance and not useful.

alisonhenley · ‎02-27-2025

Current state - You can only use color conditional formatting on numerics in the value section of a pivot table. But it would be nice if you could also apply color formatting on text. An example of this would be green on the value 'Confident', orange on the word 'At Risk' and red on the word 'Not Possible'. This text would be values existing in our database, not something created within Sisense.

ni-rwhite · ‎02-27-2025

Add the ability to adjust the BaseTableMaxThreads at the Data Group level. This will allow for "right sizing" memory allocation that is consumed during the build process. For example, I have low priority elasticubes residing in the default data group. High priority elasticubes reside in a "High Priority" data group with custom settings for "Stop When Idle", RAM, etc. Currently, our environment is configured to load 3 base tables concurrently (BaseTableMaxThreads = 3). This setting impacts both high and low priority data groups. I want to be able to set my low priority data group to only load one table at a time (BaseTableMaxThreads = 1) to reduce memory consumption on the server during builds. I want my high priority data group to continue loading 3 tables at a time. The trade off is the default data group will load data slower but will consume less memory/CPU during builds, freeing up resources for the high priority data group.

Tim · ‎02-10-2025

As admin, I can get other people's dashboards using the /dashboards/admin endpoint. However, the information returned is limited: I can't get a .dash file or widget objects. I want to use my admin rights on the /dashboards/{id}/export/dash endpoint to download every dashboard, even ones that haven't been shared with me. Perhaps this could be generalised to other endpoints that limit based on dashboard permissions or other permissions: If as admin I can grant myself access to an object through the UI, then I should be able to set a flag in my API calls to circumvent these restrictions.

ccoelho · ‎02-26-2025

Currently the way the Sisense creates its query for dashboards, is it creates a common table expression for each entity created in the data model. Then applies the date filter after the join between the CTE. During this process, it looks like its scanning the entire table of the CTE, which can be problematic if the underlying table used in the CTE is really large. It will be better if the filter for dates can be applied within the CTE for such large tables, thus avoiding large table scans and help load the report faster. Is there a way this can be achieved by altering the design of the data model? or are there any plugins to support it?

mba · ‎02-24-2025

Hi, We have two cloud servers in Sisense: one for development (staging) and one for production. The staging server connects to our staging database. The production server connects to our production database. All cubes and dashboards are identical except for database connection strings and names. Our Git branching strategy follows these steps: Create a feature branch from staging. Make changes and push them to the feature branch. Open a pull request from the feature branch to staging. Test changes in staging. If approved, merge staging into master (production) to deploy changes. The Issue Git integration tracks database connection names, meaning both servers must either run on staging data or production data—this is not feasible for us. Proposed Solution We suggest implementing a decentralized environmental variable for storing database connections. For example: Use {database-server-name} as a placeholder in configurations. Set database-server-name = db_server_staging on staging. Set database-server-name = db_server_production on production. This would allow the same codebase to dynamically connect to the appropriate database without manual adjustments. Would love to hear your thoughts on this!

Sisense Community

Make Dashboard Import in Linux as good as it was in Windows, or better.

Sisense GenAI - Allow AWS Bedrock as LLM Provider

Filtering by column in table widget

Ability to increase the number of recently used Drill-in fields that display when right clicking

Table widget type, Cannot Scroll Right

Add indicator for downloading a widget

Date Filter - Improve Calendar selector user experience

Enhance table widget page controls

SQL Snippets Functionality in Sisense Fusion

Regular Expressions in Custom Sisense Tables

Allow Tolerations and Annotations To be Set on Pods Deployed By Sisense

Ability to add many items to add to widget at once

Multi-Axis Chart

Allow adding pulse alert to all types of widgets

Pulse alerts management

Allow conditional formatting on text instead of only numerical aggregates

Ability to configure BaseTableMaxThreads at the Data Group level

REST API admin access on all endpoints

Optimize data model for improving performance

Different database connections on staging server vs production server