On the Analytics page, there is a menu on the left where dashboards are listed. It is possible to create folders to organize dashboards. Folders can be nested within other folders. Currently, It is not possible to drag and drop one folder into another. This would be useful to have. ... View more

There are many scenarios where a model contains data for many distinct groups, such as customers, and you want viewers to only have access to the data that pertains to their specific customer. This is easily implemented with row level security, when there is a data column that uniquely identifies each customer. But what if you have a requirement that certain types of viewers should see all columns of data per row, while others should not have access to certain columns? Here is an approach that can be implemented right out of the box in Sisense. The one prerequisite is that any table that contains sensitive data must have a column that uniquely identifies every row, i.e. a primary key column. For every table that contains sensitive data in certain columns, create a new table that contains the original table's primary key column, a binary "switch" column with a name like [Access Allowed] and a column for each of the sensitive columns. Remove the sensitive columns from the original table. Modify the import query to load only the non-sensitive columns in the original table. Modify the import query to load the new table with the primary key and sensitive columns of the original table twice, once with [Access Allowed] set to 1 and the second time with 0 and blank (or null) for all the sensitive columns. Associate the new table to the original table by primary key column Create a dimension table for secure access with the column [Access Allowed]. One row with value 0, one row with value 1. Associate the dimension table with the sensitive data table by the [Access Allowed] column. Set up a data security rule on this column, assigning the secure user group to value 1 and the general group to value 0 If there is a hierarchy greater than two levels of column-level data security, this model can be extended to create additional one-to-one related tables to the original table. ... View more

This is for LiveConnect data sources using Snowflake. We cannot filter Datetime columns at the hours level. Either "last n" hours or "between 08:00-12:00" as example. I would like to see this added as a capability of filters. ... View more

Scenario: embedded Sisense By default, when creating a new widget, Sisense puts the user into the widget "Wizard Mode", which then requires the use to click "Advanced Configuration" to view the full-feature widget editor. We don't want our users to use "Wizard Mode" and to always be placed directly into "Advanced Configuration". This should be a configurable setting at the Admin level. ... View more

There are some dashboards where we don't want people messing with the filters.  Or where filters aren't needed to be changed, and we want the maximum "real estate" available for the body of the dashboard. I know you can hide the left- and right-hand panes with script, but this really should be an option exposed in the dashboard designer UI, as a setting for that dashboard. Example: Filter Pane:  Show [default]; Collapsed [but user can expand]; Hidden [user can't expand it]   ... View more

Because a non-trivial amount of the population is colorblind, it's a best practice to never rely solely on color when indicating behavior or status of a UI element. The filter-pane buttons are by default, I think, green for positive selection, red for exclusion, and grey for unselected. It would be better if there was also a small icon in the button that would indicate checkmark if positive, "X" if negative, and blank if unselected. Or perhaps, if Unselected (red), show a thin "X" over the whole body of the button. Thank you. ... View more

It seems strange to me that each time I need to add another table to my model, I have to re-enter all the connection (or pick a recent connection). If i have 10 tables in my model, they all have their own individual connection information. If a server name ever gets renamed, it'll be a crazy headache for us. There should be a place where you define the distinct list of actual database connections (one per server or database), give it a name, apply security, etc. And then when you go to add a table to a data model, at that point you pick from the previously defined available list of connections. ... View more

For users who wish to receive their Dashboard contents using the Subscription service, Sisense supports embedded emails or PDF format only. For convenience and expedience, I would like to see support for users to receive compatible Dashboards (e.g. Pivot Tables) directly as an Excel attachment. This will help for users who wish to receive regular emails containing important data in Excel format for integration with other systems.  ... View more

We support multiple applications of data within a model, as there is crossover between the applications; however, our customers have granularity to choose which application data with which they are allowed to see when they create new dashboards. We use column level security for attributes today so that Application A author can only see table of data pertaining to application A while Application B author can only see tables of data pertaining to application B (note that a user can have both author rights and see all both application data). We found that this does not pertain to Shared Formulas.  This now increases the "noise" that authors see, as they are seeing formulas for an application that isn't something they can readily use. ... View more

When you export a datamodel to a .smodel file, the file includes connection information (server name, password, etc.). I would like an option to exclude that information when I click export. The export dialog already offers check boxes for Data Security, Scope Configuration, etc.; this feature could be just another one that says "Connection Information". Ideally, I'd like it to exclude the connection information by default, so users are forced to explicitly ask to include it, which will remind them to consider the file as sensitive. But I understand if you don't want to change default behaviour that other users are used to. When you import a model that has had this information removed, the import should let you to enter new connection information, or leave it as placeholders like Server=0.0.0.0 and password=Password so you can enter the information after importing. Sisense GIT already removes this information; this feature could work in a similar way. You could even deliberately make GIT's "non-tracked entities" all appear on the list of export options. GIT per this page: https://docs.sisense.com/main/SisenseLinux/asset-translation-and-management.htm?tocpath=Git%20Integration%7C_____3#Non-trac ... View more

We want to rotate the API key for our system user but need to make sure there's no downtime.  This means we need to have 2 keys working in parallel for the same user for a period of time until we can cycle all of our services to pick up the latest api key. The problem is as soon as the API key is rotated, the old key immediately stopped working.   Majority of systems out there support key rotation (like allowing a time delay before the old key expires like FB app, or ability to temporary create a second key and then we can promote it as primary once we are ready).   Key rotation is a best practice for security principles. ... View more

**Please note this idea was migrated to the Product Feedback Forum from older submission areas** Designers cannot save formulas for shared use. This is problematic in two scenarios: 1. End users (our customers’ customers) are Designers 2. Data models are shared across multiple tenants (with row level security) Without this the customer is forced to either manage hundreds of separate data models, which is not sustainable, or to remove all ability to save formulas, which is not acceptable for users. The “Shared Formulas” feature should allow for permissioning; something similar to “limit sharing to users’ own groups” would work. ... View more

Two problems: Datamodels store old connection information without the user being aware. That increases the chance of accidentally exposing credentials to a different security context. Sisense R&D said that the reason is to show Recent Sources. When you change a dataset, you can end up with two copies of the dataset, which is confusing.   Ideas for improvements (take some or all): Sisense could track the Recent Sources separately. Then Sisense could automatically remove empty datasets. Sisense could show empty datasets under Data Sources in the data model editor UI, and give the user a delete button for them. The Data Model editor could have a drag-and-drop to move tables between data sources. When you click export, there could be a checkbox "Remove data source connection information".   More detail about the problems here: https://community.sisense.com/t5/support-portal/bd-p/SupportPortal?page=casedetails&caseId=500Pk00000Es4PyIAJ and here:https://community.sisense.com/t5/help-and-how-to/models-have-empty-datasets/m-p/20632#M222   ... View more

When utilising the Fiscal Year functionality, it is frustrating that there is no option to display the calendar year as a formatting option. We are based in Australia and our Fiscal Year starts in July, so our 2023/2024 Fiscal Year (called 2024) runs from July 2023 to June 2024. If I create a simple pivot with our Date, Year (Calendar Year formula) and Fiscal Year (formula in format YYYY/YYYY), then you can see that the date is actually distorted.  There is no way to display that this date actually falls in 2023, which is the case for the first two records in the below pivot. Applying a filter with a date range handles this correctly, but it is confusing for our Finance department as to what date this is referring to. I've connected with Sisense support and they've provided a solution for a Date Display Field (thanks @AssafHanina) which does solve the issue, but then we need to have complicated rules for dashboard designers to use X field on their Dashboards but Y fields on filters, etc. I feel like an additional date format of "cy" for Calendar Year would solve this issue from the display side and make things much simpler.  Some logic already exists for "yp" for the previous year, this would be very useful for our designers to have this additional option and to keep the date as one field rather than needing a second. Has anyone else encountered this issue or would find this useful? ... View more

When filtering on a numeric field and using a Value type filter, I often want to filter on a dynamic value. As the Ranking type filter can take a formula, I would make good use of a Value type filter that also allowed for a formula. ... View more

When a widget returns no data and is displayed in column format - it would be nice to have an option to show the column headers only to give users a reference point as to what data will be shown. Thanks ... View more

Hello, In a multitenancy environment, it would be useful to be able to define different "look and feel" theme for each tenant. Currently, the one define on the system tenant is applied to every tenant. Thank you. ... View more

---Summary:--- When you drill, create a filter. Link new filter and the drill-breadcrumbs, so if you change one, it changes the other. Make it an optional, per-widget setting. ---Details:--- Sometimes I build a dashboard with a "main" widget for the user to explore, plus a few indicator widgets above it. It'd be nice if, when the user drills on the main widget, their choices were applied to the dashboard filters. That way, my indicators would reflect what they've drilled into. But that should be an option in the widget settings; other times I have a dashboard with several major widgets and drilling into one should not filter the others. When the user un-drills (clicks the cross or a breadcrumb to return to the overview), that should automatically remove the associated dashboard filter. And if the user alters or removes the dashboard filter, that should carry over to the drill-down breadcrumbs. ... View more

When replacing a server, or testing an upgrade, we often find our clients taking a backup of their Sisense database and restoring it to another server. After updating the server identity in the mongodb, it's pretty much ready to go. However, use dashboards all reference the old server and have to be updated. This is a manual process that the users themselves one dashboard and data source at time. An administrator cannot easily do that work on their behalf. Acknowledging that there is a replace_datasource API call that allows you to apply a new server and data source to a single dashboard, I would love an easier a way to update just the server across all dashboards. ... View more