1. View all history of builds and its corresponding logs from the cubes. Because, I could not see the last build failure reason, if another build got started. I need to wait for another build to complete or fail. 2. View all history of changes and provide a way to revert as in Google docs for both the cubes and dashboards. Some times, if something went wrong, we should just be able to revert to the previous version and continue from there. 3. Provide a way to view the list of cubes in the queue waiting for the build. Also, allow remove or disable them for a period or rearrange the queue to build. This will help in prioritizing something manual on demand. 4. If a cube build fails due to the memory or other configurations issue, provide suggestions like what has to be changed and based on what before triggering another build. 5. Provide a page to derive the suggested the configurations like memory, cpu, timeouts etc by collecting details like 1. Number of cubes, 2. average cube size, max cube size, min cube size, or number of cubes by size range say <5g, <10G, <20G, <40G etc.., 3. Frequency of the build per cube etc.. 6. Provide a page to view all the slow running dashboards, slow running queries and some suggestions to improve it. 7. Some times, if a dashboard got changed and republished, it is not getting applied to all the users. Provide a way to view the version of the dashboard the user may view. 8. Between builds, if there is not much change in the data, Sisense build should go faster. Provide a way like one common place to build each table from other sources individually and keep it ready. From there, if we build say functional cubes, it should build in flashing fast using the locally stored data. I see the cubes are pulling the data faster from relational db but very slow from mongodb. Now, if we are pulling data from another sisense cube or from the source no big performance difference. 9. Also, I am not sure, if we are restarting the nodes, should we necessarily mark the cubes in queue as failed, instead adding back to the queue as it was before the restart and just marking the actual cube got failed should be good enough. More later .. Thanks, Muthusamy J ... View more

Idea: Allow developers to build/test add-ons in a local environment rather than requiring a live environment. Note that this would be for the purpose of creating custom add-ons for additional functionality that would require testing on the "out of the box" Sisense UI. Background/Context: In most development workflows it is common practice to work on your code locally on your machine and deploy to a local server aka "localhost" to test/view your work in the browser. An example of this is building and deploying a local React.js app to your browser. As you make changes to the code it will recompile locally and update what you see on your localhost. If you're using Sisense out of the box however, to test/view any changes to an add-on developers are forced to upload the files in some way to a live Sisense Environment. This not only limits the innovation of add-ons to developers with an active license and live environment, it makes it painfully inefficient to develop customizations on top of the Sisense application. I understand there are likely some business concerns with allowing the use of the product locally but I'd argue that there are ways to prevent that, such as enforcing some default sample data etc., but in such a way that would give developers a "local playground" to develop/innovate on. ... View more

The helm chart supplied with Sisense allows global annotation of all service accounts within the sisense namespace. For example I can annotate an AWS role that is able to be assumed by pods: helm upgrade sisense ${sisense_chart} --namespace sisense \ --reuse-values \ --set global.serviceAccountAnnotations."eks\.amazonaws\.com/role-arn"=${pod_role_arn} While this covers most of the pods by updating all the sisense-* service accounts in kubernetes the ec-build pod (the one that actually builds the elasticube) only uses the default service account in the sisense namespace. A workaround is to annotate the default service account: kubectl annotate serviceaccount default eks.amazonaws.com/role-arn=${pod_role_arn} --namespace sisense But it seems odd that the pod would a) assume the default service account when all other pods have service accounts explicitly defined for them and b) despite having gone to the trouble of wiring up global service account annotations in helm for them not to be applied at the final step of elasticube building. This specific use case is for supplying web identity tokens to a JDBC driver so that you can interact with AWS by using a specific OIDC assumed pod role, rather than using an EC2 role or worse, static credentials in a file or connection string. Even more specifically using CData JDBC parquet driver with S3.   ... View more

It would have been great if there was a quicker way to update the SSL certificates on the Sisense server without having to run the update install. There are clients who do not wish to provide internet connection on the server once Sisense install is complete. As I understand it, if Sisense was installed with internet connection on, then we need to have internet connection in order to re-run the installer successfully. So we will have to make a request to the client to provide internet connection again to run the update install. It would have been good if there was an alternative way to update the SSL certificate.  ... View more

Windows Sisense currently has no way for us as administrators to control how much ram is being used by elasticubes. From looking at the community site, it appears that linux has a way to do this through data groups, but when consulting with support, I have been told to increase our resources, simplify our models, etc.   The big problems that we have observed at my company is that 1. Sisense seems to take up the resources it is given - when ram is increased, usage percentage stays at the same level 2. If something does go wrong and resources begin to get consumed, there are no guard rails in place to stop whatever incident is happening from taking down the whole server This second case has happened only a few times in the years we have had Sisense, but I don't like that I have no way to be proactive about these issues.  ... 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

When a Sisense server's IP address changes, you have to reinstall Sisense. I want a script or button that changes all the relevant settings. We need it because we're planning changes to our network. There are other reasons that an IP address might need to change, e.g. I might restore from a system image backup to a different location, or I might start a new server and, after testing, want to redirect my old server's IP address to it. We'll do it by reinstalling, but that feels like more work than it should be. ... View more

Current behavior of the Simply Ask feature doesn't support automatic saving of the modified NLQ model to the "*.dash" file. So you loose your development work after exporting the dashboard with already enabled and tuned "Simply Ask" to a "*.dash" file. After importing this dashboard back to Sisense the feature is automatically disabled. Also if a developer will enable it manually it starts running based on the "By Default" NLQ model. This forces to redo all the work on the model back again which is time consuming and not efficient. We expect Sisense to consider in the future the development work on making this more convenient for a BI engineer. If a "Simply Ask" feature will be automatically enabled on an imported dashboard with a corrected model, it would be beneficial for dashboard deploy automation and will reduce unneeded additional manual work on setting up this feature again and again for different working environments for the same dashboard. ... View more

Right now, if you're making significant changes to an existing cube, the only way to verify that you haven't broken something is to actually do a build. I'd like a Verify or Validate button, next to the Build button, that would do the initial steps of the build process and then stop.  For example, determine if the metadata in the table can actually be retrieved from the underlying data source.  Or checking datatype mismatches in existing joins.  And so on.  Just leave out the last step where you actually retrieve the full data set and then build the cube. This would save time during the development process. ... View more

Please enable the possibility of selecting a default CSI (storage class interface)  from a set of existing CSIs so that it may be used as default Sisense persistent storage option. This is is a necessary feature for persistence of storage in cases such as autonomous cluster scaling or rebalancing, as well as disaster recovery.   ... View more

As of L2023.3, in Sisense’s Helm Charts , “Tolerations” are supported by the micro-services. It prevents end-users from configuring “Taints” on the node that they want to dedicate to Sisense. Since no “Taints” are configured, so all nodes can become eligible to host Sisenses’s pods. They experienced that scenario when pods from some other application services were scheduled on a Sisense node. Would you please consider allowing the pods to be protected not only with  “Toleration” but also with “Taints”. The justification for this is that, even though it is mentioned in prerequisites documents that Sisense should be installed on dedicated servers, there is a non-negligible factor from the customers perspective that is the overhead administrative costs, especially for customers who must already manage numerous clusters for several applications, multiple environments, and redundancy.   ... View more

Some end-users have several environments where they must provision Sisense and they strive to standardize and automate the processes as much as possible for efficiency. It would be great to be able to extend standardization and potential automation of configuration to the Helm Chart level: Please include some ways to enable feature or disable feature with the helm chart so that if we want to enable file management everywhere we could provide a value to all our helm charts so we can have uniform configuration. ... View more

Hi. It would be cool to have a possibility do use external RabbitMQ instead one provided with Sisense Provisioner and hosted in Kubernetes cluster as StatefulSet. We would like to use managed rabbit cluster from AWS. The same case could be for MongoDB with AWS Document DB. ... View more

I have a client that has SSO users and non-SSO users.  On Sisense advice, we have created a separate tenant for the non-SSO users.  We expect that those users would have all user email features of users as if SSO did not exist on the system.  We are finding that the new user invitation email is not enabled for these users (among other email functions).  Therefore, these users are not able to set their passwords when they are created.   As a result, we are using a common password for 600+ users.  This is obviously not satisfactory.  Those tenant users can now log in and change their password, but we have no way to enforce that they do this as we would with an invitation email.   R&D has told us this is the expected behavior (refer to case #00746676).  This behavior is not working well for my client.  I would like all user email features enabled for non-SSO tenants. ... View more

Currently there’s no way on the Sisense UI to have an overview of when the next ElastiCube Builds are set for. Having such info available would make it possible to easily select relevant time slots to run load testing scripts for instance, but also more broadly to help understand and finetune the current Builds orchestration. In order to do so, we would like for admin roles to have access to a single table-like page that would list all the Builds scheduled in the next 24 hours with the following columns: ElastiCube name Build start date Build theoretical end date* Last successful Build duration * Build theoretical end date = Build start date + Last successful Build duration * (or NULL in the rare event where the Build has never succeeded before) Additional features: CSV Export Sort option on column headers Pagination Note: a single Elasticube can have more than one entry (in the example below, we assume the admin user opens the page at 3:00 PM and the ElastiCube_B's Build is launched every 2 hours). ... View more

Would like to have the ability to share multiple dashboards at one time instead of 1 at a time. Moving to Sisense from another software and having to share 50+ dashboards is very time consuming. ... View more

To ensure security and compliance for HIPAA, we need to know when users export data. Specifically, we want to know how many rows were exported so we can check for malicious use.    ... View more