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

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

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

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

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

**Please note this idea was migrated to the Product Feedback Forum from older submission areas** We are hosted on Azure for Sisense. When looking at hosting Snowflake in AWS, it complicated out could architechture too much. We are looking for an option to continue to host using Azure, but also benefit from Snowflake. ... View more

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! ... 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