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.
Ability to Specify Provider in Pulse Alerts
-------------------------------------------------------------------Problem Statement: Inability to Scope System Alerts by Data Provider Currently, Pulse System Alerts for build failures are binary—either enabled for everything or disabled. In complex enterprise environments, we often run hybrid deployments where ElastiCubes are powered by vastly different backend providers (e.g., legacy MSSQL/Oracle vs. modern Snowflake/Redshift/BigQuery). When a legacy database goes down for maintenance, or when we have non-critical local CSV cubes failing, our administrators are flooded with Pulse notifications. This noise often causes us to miss critical failures in our primary Snowflake cloud data warehouse, which has direct cost and SLA implications. Proposed Feature: Provider-Based Alert Routing We need the ability to configure Pulse System Alert rules based on the underlying Provider or Connectivity Type of the ElastiCube. Specifically, in the Pulse > System Alerts > Build Failed configuration, please add a condition logic or filter that allows us to include/exclude specific providers. Configuration Example: Alert Rule 1: Send to CloudOps Team IF Build Fails AND Provider = Snowflake, Redshift. Alert Rule 2: Send to DBA Team IF Build Fails AND Provider = MSSQL, Oracle. Alert Rule 3: Do NOT send alert IF Provider = CSV, Excel. Business Impact Noise Reduction: Eliminates "alert fatigue" by filtering out expected failures from dev/test environments or legacy systems. Targeted Incident Response: Ensures the right team (Cloud Ops vs. Legacy DBAs) receives the alert immediately, reducing Mean Time to Resolution (MTTR). Cost Management: Helps prioritize failures that impact billable cloud compute consumption.
Add robust folder management
We have created many folders (and subfolders) to help us organize our dashboards. It is currently very cumbersome to share folder access and ownership, which must be done for every dashboard within the folders. It would be nice if there were an easy (and native) way to share access to a folder and every dashboard within it, or to change ownership of a folder.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.
Do you get booted out of Support case drafts?
I would like to see the Support Portal not auto-refresh auto-log-me-out while I'm working in there. I too often get booted out of drafts of support tickets by being auto-ejected and logged out of the support portal and community site. I'm just actively typing along in the Case Comments box, and the page refreshes and I'm logged out, losing all my work in the process. Of course, this is my reminder to stop using the Support Portal UI for drafting my comments, but it's so tempting to just work the way I expect to be able to work, and then I forget and get burned.
/dashboards/admin not working on Linux 2025.3
Hello, We have been using Linux version 2025.2 and having no issues with the endpoint "/dashboards/admin". Now, we upgraded to 2025.3 and the "/dashboards/admin" endpoint is returning 500 error code 'Internal Server Error'. Other endpoints are working as expected. Wondering if there is a new endpoint to be using now, or some server setting we need to adjust. Appreciate the any assistance.
Add Expiration Date for User Accounts in User Management
In the current user management system, there is no way to define a specific expiration date for a user’s access. I would like to propose adding an “Access Expiration Date” field to each user profile. 🔧 What the feature should do: Allow administrators to set a specific date on which a user’s access will automatically expire. After reaching that date, the user should be automatically deactivated or lose access without requiring any manual action. Ideally, the system should also: Display the expiration date in the user overview. Send optional notifications shortly before expiration (to admins and/or the user). Allow editing or extending the expiration date at any time. 🎯 Why this is useful: Makes it easier to manage temporary users (consultants, interns, project-based accounts, external partners). Prevents forgotten accounts from staying active longer than intended. Ensures better security and compliance. This feature would greatly simplify user lifecycle management and reduce manual administrative work.
Update Connection Management API to allow the ability to automate updating Key's
Currently the connection management API allows a user to update connection information in an automated way. But when using KeyPair auth as Snowflake will be requiring very soon - we cannot use the same API to update the physical key. The current flow requires an admin to manually update a key by copy and pasting it into the file management. It is incredibly tedious and cumbersome for a user to have to update these one by one. I imagine more Sisense customers will realize this pain as the Snowflake timeline for KeyPair auth nears.Additional Sisense CloudMS Upgrade Reminder
With most Dev/Prod Cloud Upgrade reminders often being sent 1-3 weeks ahead of time, a customer is respectfully requesting to add a second reminder preferably the day before the scheduled upgrade in order to make sure they are prepared and can make any changes to their resources or timelines.
