Troubleshooting | Sisense Community

Community Feedback
Chapters
Events
Forums
Blogs
KB Docs
Support
Learning
Use Case Gallery

Categories

MoreDiscussions

Knowledge Base Docs

Troubleshooting

Created Apr 15, 2026

0 members

151 discussions

Troubleshooting Tips and Tricks

Troubleshooting
Solving the "Zombie Connection" Race Condition in Istio/Envoy [Linux]
Introduction: If you are running Sisense on Kubernetes with Istio (ASM), you may encounter intermittent 502 Bad Gateway or 503 Service Unavailable errors during JAQL queries, even when your pods appear healthy. Step-by-Step Guide: 1. The Problem: Timeout Mismatch By default, the Istio Ingress Gateway (Envoy) tries to keep TCP connections to backend pods alive for as long as possible (defaulting to 1 hour). However, the underlying GCP VPC network or the Sisense application pods often have much shorter idle timeouts (usually 60 seconds). This discrepancy creates a race condition: A connection sits idle between dashboard refreshes. The Sisense pod or the GCP network closes the connection due to age. At that exact microsecond, Envoy attempts to reuse that "established" connection to send a new JAQL request. Because the other end is already closed, Envoy receives a TCP Reset (RST). Log Examples In your Istio Ingress Gateway logs, you will see the following flags: 503 UC: Upstream Connection termination. 101 DC: Downstream Disconnect. 2. The Solution: EnvoyFilter Alignment To fix this, you must force Envoy to be more "aggressive" than the network. By setting Envoy’s idle_timeout to 45 seconds, Envoy will proactively kill its own idle connections before the GCP network or the Sisense pod has a chance to drop them silently. Critical Implementation Detail Many users attempt to apply the filter in the application namespace (e.g., sisense), but if sidecar injection is not enabled, that filter will do nothing. The filter must be applied where the Envoy proxy actually lives: the istio-system namespace. The Fix Apply this configuration to target the Ingress Gateway specifically: apiVersion: networking.istio.io/v1alpha3 kind: EnvoyFilter metadata: name: sisense-idle-timeout namespace: istio-system # Must be in the same namespace as the Ingress spec: workloadSelector: labels: app: istio-ingressgateway # Targets the Gateway proxy configPatches: - applyTo: CLUSTER match: context: GATEWAY patch: operation: MERGE value: common_http_protocol_options: idle_timeout: 45s # Closes connection before the 60s VPC/App limit Conclusion: This ensures that the Ingress Gateway the only Envoy proxy in a non-sidecar setup manages the connection lifecycle properly. By "hanging up" first, it prevents the use of "zombie" connections, eliminating the 503 UC resets. 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.
Liliia KislitsynaPosted 1 month ago
0
Troubleshooting
Minimum Information Required for a Sisense Support Ticket
When submitting a ticket to the Sisense Support Team, please always aim to provide clear, categorized details regarding your issue. By supplying all possible answers upfront, you eliminate the need for back-and-forth communication, allowing our engineers to begin investigating and resolving your issue immediately. Ensure you include the following: 1. Problem Definition (What is the problem?) Clear Description: Explain the issue and the functionality that is failing. Expected vs. Actual Results: Clearly state what you expected to happen versus what actually happened. Steps to Reproduce: Provide a specific, step-by-step guide on how the support engineer can replicate the issue. Visual Proof & Network Traffic: Attach uncropped screenshots or screen recordings showing the error or behavior. For web interface issues, please also attach a HAR file (see: Generating a HAR file for troubleshooting Sisense ). 2. Scope and Business Impact (Who is affected?) Affected Users/Dashboards/Cubes: Note whether the issue impacts all users, a specific user group, or just a single user. What is unique about the affected group? Does the problem occur across the entire platform, or only on specific dashboards or ElastiCubes? 3. Frequency and Pattern (How often does it occur?) Timeline: Exactly when did the problem first occur? Did it ever work as expected in the past? 4. Environment and Recent Changes (Did something change?) Recent Events: Did the issue start after a specific event, system change, or Sisense version upgrade? Load Changes: Has there been a recent increase in the number of users, data volume, or concurrent builds? Infrastructure Health: Do you observe any infrastructure utilization outliers (e.g., spikes in CPU or RAM) during the occurrence of the problem? For Cloud Customers: Provide the URLs to the affected Dashboard/ElastiCube and, if possible, relevant usernames support can use to troubleshoot. Please make sure the Support Access is enabled on the instance. 5. Technical Artifacts (Logs for On-Premise Customers ) Always attach the relevant server-side logs based on the issue. Identifying the Service: If you are not sure which service is affected, use the Sisense Linux Services Guide . The log name corresponds directly to the service name. Extracting Logs: For step-by-step instructions on pulling these files, see: How to identify and download logs from the Sisense server . By packaging your problem description, business impact, recent environmental changes, logs, and a HAR file into your initial request, the Sisense team can bypass the standard fact-finding phase and begin actively resolving your issue immediately.
Liliia KislitsynaPosted 2 months ago
0
Troubleshooting
Elasticube stuck in "saving files" phase and unable to build cube [Linux]
Step-by-step guide When building an Elasticube in Sisense Linux, the process may halt at the “Initializing,” “Saving files,” or “Attaching cube” stages, especially after manually cancelling a build. Standard service restarts do not resolve these stuck states. 1. Check RabbitMQ queues for stuck messages Sometimes, message queues hold up the completion of the build. Command (bash): kubectl -n sisense exec -it sisense-rabbitmq-0 -- rabbitmqctl list_queues --formatter pretty_table | grep -v 0 Review the output for queues with unexpected message counts. Screenshot: Terminal with rabbitmqctl command output highlighting nonzero queues. (Description: Output showing a queue with many pending messages that may indicate blockage.) If stuck messages are found, consider purging the queue. 2. Identify and remove stuck cube build entries in MongoDB Persistent build entries can block new builds. Find your MongoDB pod: kubectl -n sisense get po | grep mongo Access the MongoDB pod: kubectl -n sisense exec -it <your-mongo-pod-name> -- bash Enter MongoDB shell: mongosh Switch to Sisense's 'be' database: use be Find running build entries: db.buildLogData.find({status:"RUNNING"}) (Description: Output should show records with your cube’s name and running status.) Delete stuck builds for the specific cube (replace 'cube name' accordingly): db.buildLogData.deleteMany({'dataSourceTitle.value':'cube name'}) 3. Retry the cube build Return to the Sisense UI and try building the cube again. Troubleshooting Tips Double-check the cube name before using the MongoDB delete command. Always back up your database before performing direct deletions. For multiple stuck cubes, repeat the deletion process for each one. If problems persist, review Sisense system logs and reach out to Sisense Support. Conclusion Sisense cube builds can get stuck in “Saving files” due to residual process states, especially after manual cancellation. Clearing RabbitMQ queues and removing “RUNNING” build entries from MongoDB resolves this for most users. Always exercise caution when making database changes. References/related content Build Log Walkthrough How To Troubleshoot Build Failures (Linux OS) 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.
oleh_dukhPosted 4 months ago
0
Troubleshooting
Troubleshooting ElastiCube build failure: SQL MALException !ERROR: GDKsave: failed name [Linux]
Step-by-Step Guide: 1. Understand the error Error Example: 9500 | ElastiCube error Check the farm validity and try recovering the last successful build. Try rebuilding the cube. BE#211715 Failed to create table: <table_name>. SQL: MALException:!ERROR: GDKsave: failed name=<id>, ext=tail, mode 0. Root Cause: The most common cause is a low open file limit (LimitNOFILE or LimitNOFILESoft) for the containerd service, which prevents the database engine from saving files during the build process. 2. Check and Increase Open File Limits A. Verify Current Limits Run the following command on your Sisense server: sudo systemctl show containerd | grep LimitNOFILE If you see values like LimitNOFILE=1024 or LimitNOFILESoft=1024 , this is too low. B. Update containerd Service Limits Edit the containerd service configuration: sudo systemctl edit containerd Add or modify the following lines in the [Service] section: [Service] LimitNOFILE=524288 LimitNOFILESoft=524288 Save and exit the editor. C. Reload and Restart containerd Reload the systemd daemon: sudo systemctl daemon-reload Restart containerd: sudo systemctl restart containerd D. Confirm the New Limits Run: sudo systemctl show containerd | grep LimitNOFILE You should see both values set to 524288 . E. Recreate Affected Pods For changes to take effect in running pods: kubectl -n sisense delete pod <build pod-name> Verify inside the new pod: kubectl -n sisense exec <build pod-name> -- bash -c "ulimit -Sn && ulimit -Hn" Expected output: 524288 524288 3. Retry the Elasticube Build After applying the above changes, attempt to rebuild the Elasticube. The error should be resolved if the open file limits were the root cause Conclusion The SQL: MALException:!ERROR: GDKsave: failed name error is typically caused by insufficient open file limits for the containerd service. Raising these limits resolves the majority of cases. References/Related Content Sisense Linux Build Logs Overview Managing Linux Build Service Settings Troubleshooting Build Failures Due to Memory Issues (Safe Mode) Steps to Do Before Contacting Support Regarding Build Failures 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.
oleh_dukhPosted 4 months ago
0
Troubleshooting
Data indexing error: Dim table corruption found on dimension table [Linux]
Step-by-Step Guide: This error arises due to Sisense’s internal build validations, specifically the RelationDimTablesValidation check. This validation ensures all dimension tables used in table relations contain all possible key values, maintaining data integrity during query execution. More details on these checks are available in the Sisense documentation . Recommended Solutions: Enable Build Retry: Automatically retry builds after a failure to resolve temporary issues without manual input. How to enable Build Retry: Navigate to: Admin > System Management > Configuration Unlock additional build settings: Click the Sisense logo 5 times. Enable build retry: Set RetryBuild.value = true. How Build Retry works: The NumberOfBuildRetries parameter defines how many automatic retries occur after a failure (default is 0, meaning no retries unless set). When enabled, only the latest build logs remain after a retry. Configuring retry parameters: Set NumberOfBuildRetries (number of attempts). Set WaitTimeAfterBuildFailedBeforeRetry (default: 60 seconds). Click “Save Changes” to apply. Disable Validations; If retries do not help and the error persists, disable specific validation checks one-by-one to identify the problematic one: DataIndexingValidation RelationDimTablesValidation IndexingDimTablesValidation How to disable validations: Go to: Admin > System Management > Configuration Click the Sisense logo 5 times to unlock hidden settings. Scroll to the Build section. Set the relevant validation flags to false . Save changes. Conclusion: Sisense’s data integrity checks are designed to prevent the use of inconsistent data. If you encounter error 9300 related to dimension tables, enabling build retries or selectively disabling validations can resolve these issues. Always track changes and test in your environment before applying these solutions broadly. References/Related Content Sisense Build Logs Overview Building ElastiCubes L2024.3 Release Notes 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.
oleh_dukhPosted 4 months ago
0
Troubleshooting
Dashboard dates display incorrect years due to fiscal year settings [Linux]
Step-by-Step Guide Check your Elasticube fiscal year start month Open Sisense Admin or Elasticube Manager. Navigate to the Elasticube used by the affected dashboard. Locate the Fiscal Year Settings section. 2. Review the fiscal year start month Verify the month configured as the Fiscal Year Start Month. If set incorrectly (e.g., April instead of January), Sisense shifts dates into the next fiscal year, causing dashboards to display dates one year ahead. 3. Adjust the fiscal year start month If the setting is incorrect, change it to the correct start month (typically January, unless your organization uses a non-standard fiscal year). Save your changes. Conclusion Incorrect dashboard dates often result from misconfigured fiscal year settings in the Elasticube. By reviewing and updating the fiscal year start month and rebuilding the model, you can quickly restore accurate date displays across your dashboards. References/Related Content Sisense Documentation: Fiscal Year Settings: https://docs.sisense.com/main/SisenseLinux/fiscal-years.htm
Ihor YokhymPosted 5 months ago
0
Troubleshooting
Usage analytics model build failing – troubleshooting and resolution [Linux]
Step-by-Step Guide: Common Symptoms The Usage Analytics Model build fails each time you run it Reports are outdated (typically by several weeks or more) Error messages reference issues such as: "Failed to read row: [number], Error from CSV. Unexpected character." "Headers do not match, corrupted file." "Malformed content" or "connector cannot process CSV" Probable Causes Old or Incompatible CSV Files The build may attempt to process outdated files beyond your configured retention policy (commonly 30 days). These files may use a different schema, missing columns, or malformed content. Schema Mismatch After System Upgrade Upgrades (e.g., to Sisense L2025.2+) may introduce new columns to files, resulting in inconsistent headers between older and newer CSVs in your /usage/query/FinishQuery/ directory. Malformed Content in CSV Columns CSV rows may contain improperly escaped JSON or illegal characters, which can disrupt the parsing process. Step-by-Step Resolution Step 1: Check Usage Analytics Retention Settings Navigate to your Sisense Usage Analytics settings. Verify that "days to retain" is set appropriately (default: 30 days). Step 2: Remove Outdated or Incompatible CSV Files Access the File Management.. Go to /opt/sisense/storage/usage/query/FinishQuery/. Delete any CSV files older than the retention period, especially those predating recent upgrades (e.g., files before April 2025 if your upgrade was in May 2025). Step 3: Validate File Consistency Ensure all remaining CSV files have identical headers (column names). If you identify files with extra or missing columns: Remove those files from the directory. Optionally, compare headers of a few recent files to confirm schema alignment. Step 4: Address Malformed CSV Content For files noted in error messages (with line number references), open and inspect the problematic row. Correct formatting where possible: Nested JSON should be properly escaped and quoted. Columns should be separated only by commas, not other characters. If corrections aren’t feasible, remove the affected file. Step 5: Verify Disk Space Usage Analytics build may also fail if disk usage exceeds capacity. Ensure sufficient free disk space for the build to complete. Step 6: Run Usage Analytics Build After cleanup, re-run the Usage Analytics Model build. The build should now succeed with the latest, schema-consistent files only. Step 7: Confirm Data Range Check your dashboard to verify the updated date range in reports (should show recent usage, typically up to the present).: Supplementary Information and FAQs Why were files outside my retention policy being read? In rare cases, leftover or misplaced files from previous periods may remain. Cleaning up ensures that only relevant, up-to-date files are processed. What caused the schema mismatch? System upgrades sometimes add new columns to logs/exports. If both old and new format files exist together, connectors can’t parse the mixed schemas. Should I automate this cleanup? Sisense normally rotates and deletes old files per retention settings. If this fails (e.g., due to permissions, disk issues, or interrupted upgrades), manual cleanup may be required. What if errors persist after cleanup? If you continue to see malformed row errors, further check the reported line number in the CSV referenced by the error and address any formatting problems. Can I request help from Sisense support? Yes. If needed, compile error messages and affected files, and contact Sisense support with detailed information. Summary of Resolution By cleaning up old or malformed CSV files, ensuring header consistency post-upgrades, and confirming disk space, Usage Analytics Model builds will resume normal operation, and reporting data will be current. If issues persist, reach out to Sisense support with error details and relevant files. Add a disclaimer for custom solutions. DO NOT CHANGE IT THIS DISCLAIMER!!! ⤵️ 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.
Anton DiachenkoPosted 5 months ago
0
Troubleshooting
JWT token not working after upgrade - [Linux] and [Windows]
Step-by-Step Guide Confirm the Issue After upgrading your Sisense, your JWT SSO login might stop working. To check: Open your browser. Open developer tools (usually via F12 or right-click → Inspect). Go to the Network tab. Locate Your JWT Token Navigate to your Sisense instance and attempt to log in via SSO. In the Network tab, look for the request containing "jwt" in the URL. Highlight the request and open the Headers tab. Copy the request URL and paste it into a text editor. Example screenshot Decode the JWT Token Extract the JWT token from the request URL. The token is the string between "jwt=..." and "&return...". Example screenshot Use a JWT debugger such as jwt.io to decode the token. Check the decoded header section for the "typ": "JWT" attribute. Example header: { "alg": "HS256", "typ": "JWT" } Fix the Token Generation If "typ": "JWT" is missing, update your SSO script to explicitly include it when generating the token. Example: // JWT header example const header = { alg: "HS256", typ: "JWT" }; Regenerate the token and reattempt login. Verify the Fix Repeat steps 1–3 to ensure the "typ": "JWT" attribute now exists in the token header. SSO login should now work without errors. Conclusion A missing "typ": "JWT" attribute in the JWT token header can cause SSO failures after upgrading Sisense. By inspecting the JWT token and updating your SSO script to include this attribute, you can restore SSO functionality quickly. References/Related Content JWT - Debugger Tool SSO Using JWT - Sisense Docs SSO With JWT | Sisense Developers - Sisense Dev Docs 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.
Taras SkvarkoPosted 7 months ago
0
Troubleshooting
Troubleshooting Sisense helm provisioner [Linux]
Step-by-Step Guide: Sisense Helm Provisioner is a Kubernetes job that runs the Sisense installer, skipping the Kubernetes installation part. As it runs within the container, it already has all the dependencies that usually need to be satisfied on a Linux bastion. Thus, it runs on the cluster and instead of a dedicated bastion, you can use even macOS or Windows terminal as soon as you have ‘helm’ and ‘kubectl’ installed and configured for your Kubernetes cluster. 1. Checking Provisioner logs When the Helm Provisioner fails, check the logs of the container first if there is an obvious reason for the issue, e.g, a typo in the values.yaml, etc. kubectl logs -f --namespace $NAMESPACE -l app.kubernetes.io/name=provisioner If the logs in not detailed enough and you need to see more information on the issue, consider enabling debug mode for the Provisioner. 2 . Enabling Debug Mode The Helm Provisioner supports debug options, which are crucial when you need to dig into configuration or log output: Enable Sleep Mode: Set debug.sleepMode: true in your values file. This will pause the provisioner pod after completion or failure, allowing you to kubectl exec into the running container and inspect its environment: debug: sleepMode: true Enable Verbose Logging: Increase Ansible verbosity (which the provisioner uses under the hood) with: debug: verbose: enabled: true level: 3 # Set the desired verbosity level (e.g., 1 for -v, 2 for -vv, 3 for -vvv) With these flags, logs should contain more detailed information about the provisioning steps and errors. 3. Joining the Provisioner Container To execute the container for debugging, run: kubectl exec -n sisense -it $(kubectl get pods -n sisense -l app.kubernetes.io/name=provisioner --output=jsonpath={.items..metadata.name}) -- /bin/bash You can find the provisioner in the ‘/app’ folder. The “installer” subfolder contains the code of the provisioner itself, and the “configuration” subfolder contains the installation values. After applying the required changes on ‘installer’ and/or ‘configuration’, or can reinitialize the Provisioner by running “/app/ bootstrap.sh ” Alternatively, you can check the exact command that fails or temporary files, generated helm values, etc. Conclusion The Helm Provisioner is a good choice for deploying Sisense on Kubernetes, simplifying the installation process. When issues arise, checking the Provisioner logs can reveal immediate problems, while enabling debug mode offers deeper insights into errors. Joining the Provisioner container allows for direct interaction, enabling necessary adjustments and reinitialization. These troubleshooting steps empower users to effectively resolve challenges, ensuring a smoother deployment experience. References/Related Content https://docs.sisense.com/main/SisenseLinux/installing-sisense-using-provisioner-and-helm.htm 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.
Oleg ValynkinPosted 7 months ago
0
Troubleshooting
AWS ALB tagging issue during the Sisense installation [Linux]
Introduction While deploying Sisense on EKS with ALB ( https://docs.sisense.com/main/SisenseLinux/using-an-aws-load-balancer-controller-with-sisense-on-amazon-eks.htm ), you may notice that the installation has passed smoothly, but a load balancer is missing in the AWS console. Usually, it happens when a cluster doesn’t create new subnets but uses existing ones (e.g., this case: https://community.sisense.com/kb/cloud_managed_service/creating-and-deleting-eks-cluster-in-the-existing-vpc/26443 ). (On-prem) Step-by-Step Guide 1. Check if the AWS Load Balancer Controller pods are up and running. They should be in the default namespace unless you’ve changed the default utils-namespace installer option to another value. kubectl -n default get pods NAME READY STATUS RESTARTS AGE aws-load-balancer-controller b487cdd9b-254hv 1/1 Running 0 4h54m aws-load-balancer-controller-b487cdd9b-sj7xj 1/1 Running 0 4h54m 2. If they are up and running, please check the logs: kubectl -n default logs -l app.kubernetes.io/name=aws-load-balancer-controller You may see the following output: {"level":"error","ts":1758602590.9472752,"logger":"controller-runtime.manager.controller.ingress","msg":"Reconciler error","name":"sisense-ingress","namespace":"sisense","error":"couldn't auto-discover subnets: unable to discover at least one subnet"} {"level":"error","ts":1758603591.1477435,"logger":"controller-runtime.manager.controller.ingress","msg":"Reconciler error","name":"sisense-ingress","namespace":"sisense","error":"couldn't auto-discover subnets: unable to discover at least one subnet"} {"level":"error","ts":1758604591.3403745,"logger":"controller-runtime.manager.controller.ingress","msg":"Reconciler error","name":"sisense-ingress","namespace":"sisense","error":"couldn't auto-discover subnets: unable to discover at least one subnet"} {"level":"error","ts":1758605591.5673392,"logger":"controller-runtime.manager.controller.ingress","msg":"Reconciler error","name":"sisense-ingress","namespace":"sisense","error":"couldn't auto-discover subnets: unable to discover at least one subnet"} The aws-load-balancer-controller relies on specific tags on your subnets to auto-discover them. If these tags are missing, the controller cannot find a suitable subnet to provision the ALB, leading to the "couldn't auto-discover subnets" error. This is a common issue, especially if the VPC and subnets were created manually or by a different process that didn't include the required tags. 3. To resolve this, you must manually tag the public and private subnets in your VPC. The tags must follow a specific format. Subnet Type Required Tag Key Required Tag Value Public Subnets kubernetes.io/role/elb 1 Private Subnets kubernetes.io/role/internal-elb 1 4. You also need to tag your subnets with such a tag if they are used by this cluster only kubernetes.io/cluster/YOUR-CLUSTER-NAME: owned Or, if these subnets are also being used by other services, use ‘shared’ value instead: kubernetes.io/cluster/YOUR-CLUSTER-NAME: shared The your-cluster-name part should be replaced with the actual name of your EKS cluster. The value owned tells the controller that it has ownership of the resource and can modify it. 5. After adding the tags, the aws-load-balancer-controller will automatically detect the changes. It will reconcile the Ingress resource and provision the ALB. This process may take a few minutes. Check the controller logs again (kubectl -n default logs -l app.kubernetes.io/name=aws-load-balancer-controller -f) for a “Successfully provisioned load balancer” message. Conclusion A missing ALB after an EKS deployment on the existing subnets is often caused by a subnet tagging issue. The aws-load-balancer-controller requires specific tags to auto-discover and use them. By manually adding these tags to your VPC subnets, you can quickly resolve the "couldn't auto-discover subnets" error and allow the controller to successfully provision your Application Load Balancer. References/Related Content https://docs.sisense.com/main/SisenseLinux/using-an-aws-load-balancer-controller-with-sisense-on-amazon-eks.htm https://community.sisense.com/kb/cloud_managed_service/creating-and-deleting-eks-cluster-in-the-existing-vpc/26443 https://repost.aws/knowledge-center/eks-vpc-subnet-discovery 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.
Oleg ValynkinPosted 7 months ago
0

…