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.
Improve Build Notifications by Classifying User-Cancelled vs Failed Builds
I suggest enhancing our Sisense build notification process by automatically classifying emails as either “Cancelled by User” or “Build Failure.” This distinction will help us quickly identify which build interruptions were intentional versus actual system issues, improving response time and reducing unnecessary troubleshooting.
Add functionality for updating the Elasticube a Pulse Alert is associated with
When changing the Elasticube associated with a dashboard, any Pulse alerts built off widgets from that dashboard will not be changed and will continue to be affected by the old Elasticube. This is an issue if you are replacing one Elasticube with another. There is no warning / message when changing a dashboard's Elasticube that pulses will be affected. There is no way to see the Elasticube a pulse is attached to - only the dashboard (but again, changing the dashboard's Elasticube doesn't change the pulses). There is no way to see which pulses are built on top of an Elasticube from the Elasticube screen (unlike with dashboards). I would like the ability when changing the Elasticube for a Dashboard that has Pulse alerts associated to it, give the prompt option to update to the new Elasticube for Pulses as well. This could either be done: Via some new UI Via some warning (similar to when you try and delete a cube with active dashboards / pulses) - but this would then also need the secondary ability to manually change the Elasticube associated with Pulses.Enable end-to-end tracing visibility for Sisense services to complement existing metric monitoring.
Description: We are looking to send Sisense application traces to SignalFx (Splunk Observability Cloud) and would like guidance on leveraging the OpenTelemetry framework to achieve this integration. Currently, OpenTelemetry is not configured in our environment. We would like to understand: Whether Sisense supports OpenTelemetry out of the box for traces, The required steps to enable and configure OpenTelemetry in a Sisense deployment (Linux EC2, single-node, Kubernetes-based), How to route traces from Sisense to SignalFx, including configuration files, environment variables, and any required Sisense plugins or modules, Any limitations or known issues with trace capture for Sisense microservices, Example configuration snippets or reference documentation for this setup.Report Manager - Option to suppress Sending Empty Reports
Would like to see a togglable option, for example: "do not send empty reports" in Report Manager. The use case here is where a customer only wants to see a report if there is data in it. A listing of errors or exceptions, for example. Most of the time would be getting blank reports because nothing is wrong, and they only want to be alerted where there is something to take action on.Change error pages to not direct away from dashboards
Opening a dashboard which leads to a temporary error will redirect the user away from the dashboard URL to a 'dedicated' error page, e.g. 'https://xxxxxxx.sisense.com/app/main/error?status=404'. If this is a temporary error and the user refreshes this page they will never return to their intended destination - they are stuck on the error page forever. This causes confusion for our clients. Is there a way to change the way errors work so that I'm not redirected to a 'dedicated' error page and instead I can refresh the page and see my intended dashboard once the error is resolved?
Allow adding pulse alert to all types of widgets
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.Report Manager - Allow 'Event-Based' to use Pulse Alerts
I've been trailing the Report Manager add-on and was disappointed to see that the 'Event Based' option for triggering reports did not allow for Pulse Alerts to be used as an Event. It seems the current workaround is to use a tool like Zapier (so the pulse goes out to Zapier via webhook, which then creates the Event and goes back into Sisense, causing the report to be sent. This seems convoluted and I would have thought being able to directly integrate Pulses to trigger Reports seems like a natural fit.
Allow Pulse scripts to work when sending email notifications
Today, we can use plugins, dashboard and widget scripts to customize dashboard and widgets for scheduled emails as well as desktop. Same should be available for Pulse scripts which allow to modification of alert JAQL on the desktop, but the same script is not executed when sending alerts/notifications. This causes discrepancy between what the user sees on the desktop and what they receive in email.
Email templates - provide dashboard id
Currently you only provide a direct link to a dashboard. Allow the ability to have the ID of the dashboard. That way customers embedding the dashboard into their main app can load it natively into their app instead of directing the user directly to the Sisense instance.
