The Sisense Community is a place to solve problems, learn, and collaborate.
Read the stories of how people are using Sisense, and get the latest product news and Community updates.
Specific guides written by Sisense experts and trusted partners.
Find inspiration for your visualizations, or show off your best work and tell us how you did it!
Exporting a dashboard as a PDF or PNG works fine when the audience is internal, and the need is simple. But as soon as a report needs to go out to different groups, with different branding, formatted for a specific audience, that's a different use case than a general export was ever built to solve. On September 17 , we're running a live demo of Report Studio, a report design and delivery layer built inside Sisense for exactly this gap: getting data out of Sisense in a format that's actually ready for a client, an exec, or anyone who isn't going to open a dashboard. This isn't a slide deck. It's a live build, start to finish. Here's what you'll see: Building a report from scratch: widgets, text boxes, a logo, and shapes added to the canvas, then exported manually A side-by-side of a native Sisense PDF export vs. the same data in Report Studio Applying a template to the report we just built, and how much manual layout work it removes Toggling between brands live on a single report, with the recipient's brand assigned automatically based on their user or group Token substitution across text boxes, file name, email subject, and email body Export by dimension, both on demand and as part of a scheduled delivery The actual email a recipient outside your organization receives, report attached Admin-side monitoring: job history and delivery oversight at scale Register here: https://www.qbeeq.io/webinars-register Drop questions here, and we'll answer them live during the webinar!
Introduction: After a Windows server reboot, the Sisense.CLRConnectorsContainer service fails to start (Windows Event 7000 / 7006), so its connectors (e.g. Microsoft SQL Server) stop working — causing build failures, Live dashboard errors, and connectors missing when adding tables. This guide resolves it by extending ServicesPipeTimeout. Applies to Sisense on Windows (on-prem), all versions. Step-by-Step Guide: Customers usually notice this issue through one or more of the following symptoms after a server reboot: ElastiCube builds fail on cubes that use a CLR-hosted connector. Dashboards using Live data models return errors, because live queries cannot reach the connector. When adding a new table to a data model, the connector does not appear in the list and cannot be selected. The root cause is that the Sisense.CLRConnectorsContainer service failed to start during server startup. In the Windows Event Viewer (Windows Logs → System), you will find events such as: Event ID 7000 — "The Sisense.CLRConnectorsContainer service failed to start due to the following error: The service did not respond to the start or control request in a timely fashion." Event ID 7006 — "A timeout was reached (30000 milliseconds) while waiting for the Sisense.CLRConnectorsContainer service to connect." The Windows Service Control Manager (SCM) requires each service to respond within a default window of 30 seconds (30000 ms), controlled by the registry value ServicesPipeTimeout . After a reboot, all services start at once and compete for CPU and disk I/O; combined with the CLR container initializing many connectors, the default window is often exceeded, the service times out, and its connectors become unavailable. Resolution — extend the SCM service start timeout This value applies server-wide (to all services). Caution : Editing the registry affects the entire system. Back up the target key first and, where possible, perform the change during a maintenance window. Administrator privileges are required. Log on to the server with administrator privileges. Launch regedit (Registry Editor) as administrator. Navigate to the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control (registry path) Check whether a DWORD value named ServicesPipeTimeout exists in the right pane. If it does not exist, right-click the empty area → New → DWORD (32-bit) Value, and name it ServicesPipeTimeout. Double-click ServicesPipeTimeout to open it. Set the Base to Decimal . Enter the extended timeout in milliseconds. Recommended: 180000 (180 seconds). For environments with longer startup times, increase up to 300000 (300 seconds). Click OK to save. Restart the server to apply the change ( the SCM reads ServicesPipeTimeout only after a reboot ). After the restart, confirm that Sisense.CLRConnectorsContainer starts successfully and that Event 7000 / 7006 no longer recur. Optional — mitigate via startup order (can be combined) If services contend during a simultaneous startup after a reboot, set non-core services to Automatic (Delayed Start) so foundational services (Mongo, Zookeeper, RabbitMQ) start first, reducing the chance of a timeout. This works well combined with extending ServicesPipeTimeout. Conclusion: The Sisense.CLRConnectorsContainer failing to start after a reboot is caused by the Windows SCM default 30-second start timeout being exceeded under startup contention. Increasing the ServicesPipeTimeout registry value (e.g. to 180000 ms) and rebooting gives the service enough time to initialize, keeping its connectors available and preventing build failures, Live dashboard errors, and missing connectors. Setting non-core services to delayed start further reduces the risk. References/Related Content Microsoft — A slow service does not start due to time-out error in Windows . Disclaimer : This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this, please let us know.
Automating Dashboard Ownership Transfer in Sisense with UserReplaceTool Managing and deleting user accounts in Sisense can create manual processes when users leave an organization or change roles. A frequent issue is the reassignment of dashboard ownership to prevent losing Sisense dashboards when a given user account is deleted, as deleting a Sisense user will delete all dashboards owned by that user. The UserReplaceTool addresses this task by automating the transfer of dashboard ownership of all dashboards owned by a given user, ensuring continuity and data integrity. Overview UserReplaceTool is a Python-based, API-based Tool solution designed to seamlessly transfer the ownership of dashboards and data models from one user to another in Sisense. This tool simplifies and automates this process, allowing organizations to reassign dashboard ownership without manual processes or the risk of losing dashboards and widgets. All components are accomplished by using Sisense API endpoint requests. Key Features Automated Dashboard Transfer : Reassigns ownership of all dashboards from the current user to a designated replacement user. Data Model Sharing : Ensures that all data models accessible and editable by the previous user are shared with the replacement user. Batch User Processing : Capable of handling multiple user transfers to a replacement user in a single operation, enhancing efficiency. Complete Logging: All dashboards and datasource transferred are logged both in the console and in a separate log file. Setup Instructions 1. Setting Up the Environment To run the tool within a Python virtual environment , follow these steps: Activate the Python Virtual Environment : source /venv/bin/activate Create a Virtual Environment (if not already present): python3 -m venv .venv Install Dependencies : pip3 install -r requirements.txt For manual installation, including without using a Python virtual environment: pip3 install urllib3 jsonpath_ng pyyaml requests colorama 2. Configuration Edit the settings.yaml file to configure the tool. Key parameters include: Sisense Domain and Port : Specify the URL and port of your Sisense server, which is used for making API requests. API Bearer Token : Provide an admin-level bearer token for API authentication. See the Sisense API Bearer Token Documentation for instructions on generating and using Bearer Tokens. Users to Replace : List the user IDs to be replaced. User IDs can be retrieved via the Users API or using the console command prism .user._id. Replacement User : Specify the user ID of the new replacement owner of all dashboards. This should typically be an admin level user. Data Model Sharing : Enable or disable the sharing of data models with the Replacement user (True or False), usually True. Dashboard Ownership Transfer : Enable or disable the transfer of dashboard ownership (True or False), usually True. Unlike Dashboards, if a user is deleted, the datasources themselves are not deleted from the server, ownership is automatically transferred to the main System Admin of the Sisense server. 3. Running the Tool Run the tool with the following command: python3 replaceUser.py Practical Considerations Admin and Network Access : Ensure you have admin-level API access to the Sisense instance. Python Environment : Python3 and pip should be installed on the machine running the tool. All dependencies can be installed using Pip, and a Python virtual environment can be used. Once a Python Virtual Environment folder is set up it can be shared with the Tool and run directly on all systems using the same OS, but it is not cross OS compatible. By automating the transfer of dashboard ownership, UserReplaceTool provides a reliable and efficient solution for managing user transitions in Sisense. This ensures that datasources and dashboards remain accessible and under the control of the appropriate users, maintaining the continuity of Sisense resources. For further customization and configuration details, refer to the attached full Python Tool, which includes a README file and modify the "settings.yaml" file as necessary.
Filter by: