Sisense Community logo
    • Community Feedback
    • Chapters
    • Events
    • Forums
      • Help and How To
      • Product Feedback Forum
      • Strategy & Use Cases
    • Blogs
    • KB Docs
      • KB Docs
      • Add-Ons & Plug-Ins
      • APIs
      • Best Practices
      • Blox
      • CDT
      • Cloud Managed Service
      • Data Models
      • Data Sources
      • Embedding Analytics
      • How-Tos & FAQs
      • Onboarding
      • PySisense
      • Security
      • Sisense Administration
      • Sisense Intelligence & AI
      • Troubleshooting
      • Widget & Dashboard Scripts
    • Support
    • Learning
      • Sisense Academy: Free Courses and Certifications
      • Official Developer Documentation
      • Official Product Documentation
      • Official Sisense Youtube Channel
      • Sisense Compose SDK Playground
      • Official Sisense Discord
    • Use Case Gallery
    Discussions
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   
    Discussions
    • TagsChevronRightIcon
    data
    • Blog banner
      • News & UpdatesChevronRightIcon

      Choosing the Right Replication Strategy: Evaluating ADF + CDC vs. Snowflake Openflow

                                                       

      If you're delivering embedded analytics through Sisense, your dashboard is only as good as the data behind it. But how often do you think about what's happening upstream in the pipelines and ingestion architectures that determine whether that data is fresh, reliable, and cost-efficient before it ever reaches a visualization? QBeeQ is known in the Sisense ecosystem as a plugin and integration provider, but that's only part of what we do. This post is a window into the broader, strategic side of our work: architectural decision-making that happens well upstream of the BI layer but directly impacts the analytics experience your customers see. The client here uses Sisense to deliver embedded dashboards. We built their Snowflake-based data platform from the ground up:  integrations, ELT, data modeling, and governance with Sisense sitting at the top of the stack. The next question became: is our data replication approach from MS SQL Server into Snowflake the right one long-term, or should we move to Snowflake Openflow? A Platform Already in Motion Our relationship with our client didn't start with this POC. We previously helped them design and build a Snowflake-based data platform from the ground up, including data integrations, ELT processes, data models, and governance. That work gave them a solid, modern foundation for their analytics and reporting, including the embedded dashboards they deliver to their customers via Sisense. This POC was the next strategic step in that journey. With the platform stable and maturing, the question became: are we using the best possible approach for replicating data from their MS SQL Server into Snowflake? And more specifically, should we continue developing our custom ingestion approach, or move toward a more ready-to-go solution using Snowflake Openflow? Our client’s business depends on near-real-time data availability. Their operational data lives in MS SQL Server and feeds directly into Snowflake, where it powers analytics and reporting for their customers across retail, telecom, banking, and energy.  These aren't just technical concerns. They directly affect the quality and reliability of the analytics experience delivered to its end customers. The key business drivers behind this evaluation were: Faster availability of incremental data, especially for large transactional tables Lower operational risk and improved robustness Reduced maintenance effort over time Cost optimization at scale Putting Two Approaches to the Test Rather than making a decision based on vendor documentation or assumptions, we designed a structured POC to test both approaches in parallel, on the same three tables and similar data volumes, across four dimensions:  performance cost stability maintainability Option 1: Custom ADF + SQL CDC (Our Existing Solution) The key strength of this approach is control. We define the schema, manage data types, handle transformations during ingestion, and have full visibility into every step of the pipeline. This is the approach we built as part of the initial platform work:  CDC (Change Data Capture) - a native SQL Server feature that tracks only changed rows (inserts, updates, and deletes), eliminating the need to reload entire tables on every run Azure Data Factory (ADF) - Microsoft's cloud orchestration service, used here to move delta data from SQL Server to Azure Blob Storage Snowflake - which then loads and transforms the data using Snowpipe and scheduled tasks It's more engineering-intensive to set up, but the result is a robust, predictable, and highly tunable architecture. Option 2: Snowflake Openflow Openflow is Snowflake's newer, more plug-and-play approach to data ingestion. It uses Change Tracking (CT) on the SQL Server side, a lighter-weight mechanism than CDC,  and ingests data more directly into Snowflake with less custom orchestration required. On paper, it's appealing: faster to configure, fewer moving parts, and tighter integration within the Snowflake ecosystem. But as with any "managed" solution, there are trade-offs. And that's exactly what we needed to quantify. What We Found Performance Both approaches handled initial loads equally well. The gap appeared with delta loads — Openflow's Change Tracking completed incremental updates in 1–2 minutes versus 5–12 minutes for ADF + CDC. For near-real-time use cases, that's a genuine advantage worth noting. Cost This is where the picture shifts dramatically, and where decision makers should pay close attention: Openflow consumed approximately 12.5 Snowflake credits per day, translating to roughly $50/day or ~$1,500/month for this workload alone.  ADF + CDC came in at an estimated $8–15/month   That's not a marginal difference. That's a 100x cost gap on a three-table POC. Now consider what that looks like at scale. Most production environments don't replicate three tables; they replicate dozens, sometimes hundreds. If costs scale proportionally, an Openflow-based architecture could run into tens of thousands of dollars per month for a full production workload, compared to what remains a very modest cost with the custom ADF approach. For a data platform that's meant to be a long-term foundation, the compounding effect of that cost difference is enormous. Over a single year, the gap between these two approaches could easily reach $200,000 or more — money that could instead fund additional data products, analytics capabilities, or engineering capacity. For decision makers evaluating build vs. buy, or assessing the true TCO of a "managed" solution, this kind of analysis is exactly what's needed before committing to a direction. Stability & Maturity The Openflow SQL Server connector was still in preview status at the time of the POC. Runtime and canvas updates caused instability during our testing, and the solution requires ongoing infrastructure coordination. Azure Data Factory, by contrast, is a mature and battle-tested technology with a proven track record in production environments. Architecture & Maintainability Openflow introduced meaningful architectural complexity: requires Snowflake Business Critical edition (for PrivateLink connectivity) adds authentication and data sharing overhead offers limited control over target data types, and  handles soft deletes only, so hard deletes require additional handling Additional Snowflake-side transformations (PARSE_JSON, CLEAN_JSON_DUPLICATES) were also necessary. Our custom ADF solution, while more involved to build: gives full control over schema and transformations  handles deletes cleanly can be extended through a reusable automation procedure that simplifies onboarding new tables over time   Open Flow ADF + CDC Architecture Complexity ⚠️ Requires Business Critical + PrivateLink ✅ Simpler, fewer dependencies Stability  ⚠️ Preview — instability during POC ✅ Mature, production-proven Cost/month ⚠️ ~$1,500 ✅ ~$8–15 Initial load ✅ Comparable ✅ Comparable Delta load speed ✅ ~1–2 min ⚠️ ~5–12 min Onboarding new tables ✅ Fast and easy ⚠️ More setup, but automatable Schema & type control ⚠️ Limited ✅ Full control Delete Handling ⚠️ Soft deletes only ✅ Full delete support Our Recommendation The POC gave our client something genuinely valuable: a data-driven basis for a strategic architectural decision, rather than a choice made on assumption or vendor marketing. Our recommendation leaned toward continuing with the custom ADF + CDC approach as the long-term foundation. Not because Openflow lacks merit, but because the cost differential is substantial, the stability risks are real at this stage of the product's maturity, and the architectural overhead introduces complexity that isn't justified by the performance gain alone. That said, the delta load performance advantage of Openflow is meaningful. As the connector matures and if near-real-time requirements intensify, it remains a viable path to revisit. The POC ensures that if and when that moment comes, the decision will be informed, not reactive. What This Kind of Work Looks Like in Practice In the Sisense ecosystem, you may know us through our plugins and integrations. But this post reflects something equally important: our ability to act as a full-stack data platform partner. What your users see in Sisense is a function of decisions made far upstream. When those decisions lack rigor, the effects show up as latency, data gaps, and rising costs. Running a structured POC like this is often underestimated, but is one of the most valuable things we do for our clients. It's not just about finding the faster or cheaper option. It's about understanding the full picture: performance under realistic conditions, true cost at scale, architectural implications, and long-term maintainability. Every organization's situation is different. The right ingestion architecture depends on your data volumes, latency requirements, existing tooling, team capabilities, and cost constraints.  If you're thinking about your broader data strategy, not just what Sisense can do, but whether everything underneath it is built right, that's a conversation we're well-positioned to have. Thinking about your data platform strategy? Let's talk . QBeeQ is data strategy consulting firm made up of former Sisense employees and customers. We are a Sisense Gold Implementation Partner and Snowflake Select Partner

      Mia Isaacson
      Mia IsaacsonPosted 3 months ago
      0
               
    • Blog banner
      • News & UpdatesChevronRightIcon

      Every Metric Happens Somewhere: Why the “Where” Dimension Is the Missing Layer in Modern Analytics

                                               

      In our recent QBeeQ webinar, Every Metric Happens Somewhere, we explored why geospatial context is no longer a niche feature for specialized industries. It’s a core analytical dimension and one that can dramatically elevate engagement, insight discovery, and decision-making. You can view the recording , or keep scrolling for the highlights and key takeaways from the webinar. The Problem: Dashboards Without Geography Miss Patterns Traditional dashboards rely heavily on tables, bar charts, and line graphs. They show totals, trends, and rankings well. But they struggle to reveal spatial relationships. Consider common business questions: How many claims do we have? What’s our revenue by region? Which territories are underperforming? These are valuable questions, but they’re incomplete without geographic context. When you introduce the where dimension, new insights emerge: Clusters that only appear spatially Boundary effects between adjacent territories Pockets of unusually high or low performance Regional anomalies masked in aggregated totals From Niche Feature to Core Capability Maps were once considered specialized and useful for specific industries such as logistics, real estate, or field operations. That’s no longer true. Revenue, risk, compliance, performance, claims, customer distribution – these all happen somewhere. Geography cuts across industries. Approximately 80% of enterprise data already contains a spatial component. Most organizations simply aren’t leveraging it. Instead of placing a map as a static, standalone widget, leading teams are making it central to the analytical experience. Research shows interactive dashboards increase engagement and insight discovery. When you layer interactivity (zooming, filtering, panning) on top of geography, users uncover patterns faster and spend more time exploring. But friction often gets in the way. The Friction: Where Native Mapping Falls Short Many teams start with basic mapping tools that allow simple point plotting or polygon mapping. That works until analysis shifts to become more strategic. Common limitations appear quickly: Needing both points and polygons on the same map Wanting density visualizations or clustering Requiring multiple layers Enabling advanced drill behavior Supporting large-scale or time-based data When mapping tools can’t support these needs, one of three things happens: Maps sit unused on dashboards. Designers revert to traditional charts. Spatial thinking never becomes core to analysis.  Remove frictions with the QBeeQ mapping solutions SuperMap: Practical Spatial Analytics for Everyday Use The SuperMap is built for operational decision-making, understanding what’s happening right now, and acting on it. This plugin includes a range of flexible, scalable features, delivered as a zero-code solution, designed for both dashboard builders and end users. Multi-Layer Mapping (Points + Polygons) - Overlay geographic territories such as counties or states with individual location points, allowing each layer to have its own KPIs, category breakdowns, and sizing logic for richer comparative analysis. Heatmaps and Radius-Based Points - Color polygons by one performance metric while simultaneously sizing map points by another, delivering multi-dimensional insight within a single, unified view. Clustering with Drill-In Behavior - As users zoom in, clustered points automatically separate to reveal individual locations, with clusters capable of displaying proportional category breakdowns such as hospitals, police stations, and post offices. Advanced Tooltips - Enhance map interactivity with tooltips that go beyond a single value by displaying multiple KPIs, raw metrics, and calculated insights to support deeper exploration. Jump-to-Dashboard Navigation - Enable users to click on a territory to instantly filter the entire dashboard or navigate directly to a more detailed analytical view for focused investigation. Measure Switching - Allow users to toggle between different KPIs on the same map without duplicating visuals, reducing dashboard clutter while increasing analytical flexibility. Geographic Hierarchy - Support seamless geographic drill-down across states, counties, zip codes, and other levels—either directly within the map interface or through a structured dropdown selection. Deck.gl Map: High-Performance, Large-Scale Exploration While the Super Map focuses on operational clarity, Deck.gl is designed for scale and trends over time. For teams working with event streams, logistics data, or large geospatial datasets, Deck.gl provides performance without sacrificing interactivity. This plugin enables: Arc layers Hex bin density visualizations 2D and 3D polygon layers High-volume point plotting Hierarchical spatial analysis The Bigger Picture: Making “Where” a First-Class Dimension Time has long been treated as a foundational analytical dimension. Geography deserves the same status. When you: Align metrics to business geography Enable exploration instead of passive observation Remove friction from advanced spatial analysis Combine interactivity with spatial context You don’t just make dashboards prettier. You make them more useful. Every metric happens somewhere.  When you show that somewhere clearly, insights accelerate and decisions improve. At QBeeQ , we believe geography should be a first-class dimension in every analytical experience. Our mapping solutions are designed to remove friction, scale with your data, and make spatial insight accessible to every dashboard builder and decision-maker. Because when every metric happens somewhere, QBeeQ helps you see exactly where it matters most. QBeeQ is data consulting firm and also a Sisense Gold Implementation Partner. 

      Mia Isaacson
      Mia IsaacsonPosted 3 months ago
      0
               
    • Blog banner
      • APIsChevronRightIcon

      UserReplaceTool - Automating Dashboard Ownership Transfers - Useful for Deleting User Accounts

                                                                                                       

      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.    

      Jeremy Friedel
      Jeremy FriedelPosted 1 year ago • Last reply 4 months ago
      3
               
    • Blog banner
      • News & UpdatesChevronRightIcon

      QBeeQ Snowflake Monitor: Understand your Snowflake costs and get more value from every credit

                                       

      That’s why we built the  Snowflake Monitor , a new Sisense plugin designed to help you bring clarity and control to your Snowflake spend directly within your Sisense environment. Sisense customers can easily connect to their existing Snowflake Account Usage and Organization Usage schemas,  no custom ETL pipelines or workarounds required. The plugin ships with a pre-built Elasticube and a curated set of interactive dashboards, so you can start analyzing your Snowflake usage and costs within minutes.   Snowflake spend is business data and shouldn’t be locked away in admin-only views With Snowflake Monitor, data is available as self-service analytics so teams can answer their own questions instead of waiting on admins or data engineers to pull reports. This democratization of cost insights gives engineering, finance, infrastructure, and leadership teams the visibility they need without exposing sensitive admin-level access. This not only reduces the reporting burden on the small group with direct Snowflake access but also accelerates decision-making across the business. Everyone gets the insights they need when they need them. And because dashboards are built in Sisense, they can be shared widely and enriched with powerful features like trend analysis and explainers. And using data directly from Snowflake’s standard Account Usage and Organization Usage schemas ensures the data is always accurate and up to date. The result is clear: visual dashboards that surface high-cost drivers, highlight optimization opportunities, and provide actionable insights for both technical teams and executives. The first step to controlling Snowflake spend is understanding the true cost drivers Too often, costs are aggregated in a single bill, making it nearly impossible to know what the spend is (in dollars) and where it comes from (in credits). Finance teams see only the final dollar amount, while engineering teams are left guessing which warehouses, workloads, or users drove the underlying credit consumption. That’s the pain: one opaque bill, two different units of cost, and no visibility into the details. The Snowflake Monitor dashboards put cost front and center and untangle the confusion between dollars vs. credits and what vs. where. Every dashboard is designed to transform costs from a black-box line item into an actionable, transparent story for everyone: Credits used across Tasks, Materialized Views, and Warehouses Highlight users with the highest credit consumption Dollarized view of spending for finance and budget tracking 6-month trend lines to show spend over time and highlight anomalies or spikes Forecasting to project upcoming costs based on usage Finance teams finally see the dollar view they need to manage budgets, and Engineering teams can trace credit consumption to specific workloads and validate provisioning decisions. Executives get a clean summary that connects usage patterns to business outcomes. Instead of one opaque number at the end of the month, teams gain a shared source of truth. Now the conversation shifts. It’s no longer “Why is our bill so high?” but “Here’s exactly which workloads and users are driving spend—and here’s what we can do about it.” Seeing costs is only half the battle The real frustration for teams can come after the bill arrives: even if you know which workloads are driving spend, it’s hard to know what to do next. Do you scale down warehouses? Rewrite queries? Kill idle resources? Without clear guidance, teams often fall into “cost whack-a-mole,” reacting to spikes without ever fixing the root issues. Snowflake Monitor dashboards are designed not just to show where money is going, but to spotlight exactly which optimizations will have the biggest impact. With Snowflake Monitor, teams can: Identify long-running queries (over 5 minutes) that could be tuned for efficiency Spot warehouses that sit idle but still rack up costs Surface the queries with the worst scan efficiency that slow down performance and waste credits Highlight the top 15 most expensive queries, so teams know where to focus first It’s not just about saving money. It’s about making sure every Snowflake credit delivers maximum value. Each of these is a direct call to action—not just a report of what’s wrong, but a pointer to where to fix it. By calling out these hotspots, Snowflake Monitor empowers technical teams to: Fine-tune their environment for better efficiency Cut unnecessary credit consumption without sacrificing performance Strategically allocate resources instead of overprovisioning Snowflake is an incredible platform—but without visibility, it’s all too easy for costs to spiral out of control and for teams to be left in the dark. Snowflake Monitor brings clarity, accountability, and action to your Snowflake spend, making every credit work harder for your business. From aligning finance and engineering with a shared view of costs, to surfacing the optimizations that drive both savings and performance, it’s the fastest way to turn an opaque bill into a clear roadmap for improvement. And here’s the simple truth: Snowflake cost data isn’t just a bill—it’s business data. If you’re running your business in Sisense, your Snowflake costs belong there too. By bringing cost insights into the same trusted analytics environment your teams already use, Snowflake Monitor unlocks clarity, accountability, and action across the organization. Your analytics platform should tell the full story of your business—and that includes Snowflake costs. Ready to take control of your Snowflake costs  and unlock more value from every credit?  The Snowflake Monitor is now available to all Sisense customers using Snowflake. 

      Mia Isaacson
      Mia IsaacsonPosted 7 months ago
      0
               
    • Blog banner
      • News & UpdatesChevronRightIcon

      QBeeQ Asset Auditor: A smarter way to manage your Sisense data assets

                                                               

        Optimize to cut storage and processing costs, refine data models, and boost performance   Query and dashboard performance are closely linked, often hindered by bloated data models. Excessive columns, unused tables, and inefficient relationships force queries to process unnecessary data, slowing down dashboards. This leads to frustration, delayed insights, and lower productivity. Use the Asset Auditor dashboards to: See all your data sources and follow the dependencies across data sources, data models, tables, columns, and dashboards and widgets Identify table and column utilization across dashboards and widgets for better model design. Target and remove empty and unused data sources, data models, columns, and dashboards By reducing or removing unused tables and columns and optimizing queries, organizations can drive down storage and processing costs while increasing performance and user engagement.   Expose (and prevent) hidden dashboard issues affecting your users  A key risk in delivering analytics is unintended downstream effects from data model changes, causing broken widgets, missing calculations, and misleading insights. Without full visibility, teams may disrupt critical business data. Errors often surface only when users load dashboards, despite backend checks, leading to frustration, missed insights, and wasted troubleshooting time. The Asset Auditor will help you to identify the source of these errors, from deleted data sources or missing data down to widget-level errors - reducing the time to troubleshoot and identify root causes and push fixes. Use the Asset Auditor at each step to verify that dashboards are error-free when delivered to end-users. Plan and execute changes with more confidence When shared elements are scattered across dashboards, making changes can feel overwhelming without knowing the full scope. The Asset Auditor can help you confidently assess scope by identifying widget distribution across dashboards to answer the questions: Where are these widgets used? Can changes be done manually? Or do I need a script? Making changes to the underlying data models, while preventing errors, has never been easier because the Asset Auditor will show you exactly which dashboards are using which data models, and which widgets are using which tables and columns. When teams make modifications without full visibility, they risk disrupting critical business insights. By proactively assessing the impact of changes, organizations can prevent costly errors, reduce time spent troubleshooting, and maintain high-quality analytics. You can't optimize what you can't see Organizations pour resources into analytics, but without visibility into how data assets are used, inefficiencies pile up, wasting storage, slowing performance, and inflating costs.  For those responsible for maintaining Sisense environments, from data architects and model builders to dashboard designers, the challenge isn’t just creating reports—it’s ensuring the entire infrastructure runs efficiently.  Asset Auditor changes the game by providing full transparency into how data is structured, utilized, and performing across your Sisense environment.  With clear insights into dependencies, usage patterns, and optimization opportunities, teams can refine models, improve query speed, reduce storage costs, and ensure users get accurate, fast insights—all while preventing costly disruptions before they happen.

      Mia Isaacson
      Mia IsaacsonPosted 7 months ago • Last reply 7 months ago
      1
               
    • Blog banner
      • News & UpdatesChevronRightIcon

      Outer joins (preview) - Release notes

                                                       

        Introduction An outer join (left, right, full) combines data from two tables, including all matching rows and any unmatched rows from one or both tables, filling in NULL for missing data. Analytical platforms use outer joins to achieve: Broader analytical capabilities : Ensure all relevant data is visible, even if there is no exact match in another table (e.g., view all products, including products with no sales). Gaps identification : Easily spot data integrity issues and missing information or relationships, which is crucial for analysis and reporting. Outer joins in Sisense Outer joins are available beginning with 2025.4 as a preview feature (turned off by default). It is planned to be released as beta in 2026.1.1. Sisense has chosen to expose it through its data modeling attributes, placing stronger emphasis on data governance controls compared to the approaches taken by other market alternatives. Important - Outer joins are not yet ready for production, and thus are not officially supported yet. We recommend using it for testing purposes, on a dev environment only. If you’d like to test it on your own models, you’ll need to first enable the following flag: Admin → Server & Hardware → System Management → Configuration → 5 clicks on the logo → Base Configuration → Query → query.outerJoins.enabled = true Once done, you can access it through the data tab, inside any data model, when editing any table relationship. The Join type drop-down (see the screenshot below) is where you can control it. A build/publish action must be performed after changes to see them reflected in the dashboard. The default value selected is “Default”, which, for now, stands for “Inner join” as was always used in Sisense before. In the future, it might be able to inherit other flexible join behaviors from an upper-level setting/product, so by keeping that option selected, you are allowing it to stay flexible. To enforce an inner join at any time in the future, select “Inner join” explicitly. Example data - To test the outer join, use a data model with data integrity issues, such as Sample Ecommerce, which contains countries in the Dim table (Country) that do not exist in the Fact table (Ecommerce). For example, if you perform a full join between the 2 tables, build the model, and expose it in a dashboard widget, country.country ID 199 Tahiti will appear, side by side with N/A or NULL values in the ecommerce columns. Without an outer join, Tahiti would not appear at all, because there is no matching data in the ecommerce table. Known issues and limitations Planned to be addressed in 2026.1.1: Analytical engine as a prerequisite - The outer join feature is designed to work exclusively with the Analytical Engine (AE). During the preview phase of that feature, if AE is not used in a query, and the query performs a fallback (due to a “compatibility mode” setting), only inner joins will be performed, even if the table relationship indicates otherwise. Starting from 2026.1 and onwards, using and editing a join type for a relationship will be disabled if the analytical engine setting of the model is set for “compatibility mode”, rather than for “Analytical Engine”. Filter propagation issue - Filters are usually translated into WHERE statements, and are applied immediately on the source base tables, before any table join is performed. This is safe and even optimal when using inner joins. When an outer join is used, this behavior may be unsafe, as the result may still include data from tables that are not part of the filtered table. For example: Starting from 2026.1 and onwards, those WHERE statements will be propagated above the joined tables if the filters belong to the non-preserved table(s). Data security risks - Some data security features behave like filters, and although they are not exposed in the “Analyze SQL Query” output, they are implemented on top of it and may suffer from the same filter propagation symptom mentioned above. In addition, not all data security use cases were covered thoroughly before the preview version was released, and while it will be a focus of the next release, please verify it based on your own data security rules, and share with us any concerns or use cases that should be double-verified. Perspectives inheritance issue - Perspectives usually inherit the relationship attributes set in the root level of the data model. Until the next version is out, it is not yet implemented for the join type attribute, and thus needs to be defined individually per perspective. Relationship’s pane fixed visualization order - When defining a relationship between Table X and Table Y, the current interface chooses which table will be presented on the left side of the pane, and which on the right. This fixed order means that you may need to adjust the join type to achieve the desired semantic join. For example, if you want to achieve the semantic result of Table Y LEFT JOIN Table X, but the relationship visualization order is (Table X, Table Y), you should flip it and select the “RIGHT JOIN” type instead. We recognize that having to manually flip the join type can be counterintuitive, but please note that there is no limitation on the desired result, which can still be achieved in any visualized order. Planned to be addressed in future versions: Filtering NULL values in widgets - There is no current option to filter out NULL values that are created as a result of an outer-joined data set, as Sisense does not yet offer result set filters. Circular reference ambiguity - When there are multiple ways to reach from table X to table Y, the system will choose the shortest path that takes into account any active filter and required data points. That means that sometimes, mainly based on filter usage, the path of joined tables performed from table X to table Y may change. And while one path may define an outer join to be used, the other path may not define it. That is not a new behavior, and it may not be an issue if the data modeler considered it, so just make sure to take it into account. Join type flipping in query time - There could be a situation where a data model relationship is defined as Table X LEFT join Table Y, but the widget query performs Tables Y RIGHT join Table X. The result will still be the same, but for query planning purposes, Sisense might switch the join type used in the SQL to be consistent with previous query plans and ensure semantic equivalence. Feedback that we are looking to get In order to improve and deliver a much more mature version of the feature in 2026.1.1 and after, we will be highly appreciative if feedback from you, our dear users, is shared with us. Even partial feedback would be appreciated! We’ve made a list of questions to brainstorm around it, but any open feedback is welcome, and we’ll be happy to receive it as well. To share it, feel free to pass your feedback to your CSM, and/or directly to our product manager, who’s leading this initiative: Morli Ben David at morli.bendavid@sisense.com . Clarity & Naming: Is the join type interface clear and easy to understand at a glance? If you were training a new user, what aspect of the UI would you anticipate causing the most confusion? Default Behavior: Does the default join type (currently assumed to be Inner) meet your expectations, or should the platform suggest a different default based on the data relationship, or based on any other approach? Data Integrity Checks: Did any of the resulting dashboards or widgets built on the new outer-joined relationship display unexpected values, duplicates, or missing data that you did not see with the previous (inner join only) model? Query Performance: After building the model with Outer Joins, were the resulting dashboard queries faster, slower, or comparable to what you would normally expect for a similar level of data complexity? Stability: Were there any unexpected crashes, freezes, or data rendering issues when modeling with or querying data sets built using Full, Left, or Right Joins? Maturity: Given the known issues mentioned above are going to be resolved, which other missing capabilities are must-haves? Is it mature enough to go to production already? User Training/Documentation: What is the one piece of information or training material that would best help you explain this new feature's value to your data team or end-users? Missing Capabilities (Gaps) : Now that you have this control, what is the next most critical data modeling control or feature you feel Sisense is missing? It can be either in the data page or in other areas impacted, such as the dashboard/etc.  

      Morli Ben David
      Morli Ben DavidPosted 8 months ago
      0
               
    • Blog banner
      • News & UpdatesChevronRightIcon

      Sisense Performance: A Billion Records in a Single Server

                       

      Sisense Performance: A Billion Records in a Single Server Browsing our site, speaking to our team, or reading about us in analyst reviews,   you  might   have noticed that we dig technology here at Sisense. That’s why when clients and  prospects desire to push  the limits, both in terms of data complexity and quantity,   we  happily   oblige.    After asking what our recommendations would be for the most data to host in a   single  Sisense   server, one newly signed client (a prospect at the time) passed us  one   billion  trans actional   records and  three million   dimensional records   to host  in a single Sisense  node  –   that ’ s   500 GB   of data to test with  100 concurrent users   logging in and   banging  around   on the server .   We used a 32 CPU core and 244 GB  RAM  cloud machine   for the job,  in  agreement with   our straightforward specs.  We’ll cut to the chase and share the details from Load Impact below.    Tested Setup AWS Instance  -   r4.8xlarge (32CPU, 244GB RAM) 100 Concurrent Users 120 minutes 38 Max Concurrent Queries Sisense Concurrency is  defined as querying within the same mi l lisecond 2 types of usage scenarios 50 %  of users returned results from the entire billion-record dataset 50 %  of the users viewed a subset of data, simulating use by clients  who see   only their data Conclusions Query response time averaged 0.1 seconds and maxed at 3.1 seconds.  This represents   the time for Sisense to receive a query from the web appl ication and  return a result set to the client application . The Sisense Elasticube   RAM consumption remained stable at approximately 100  gb despite the 500gb+ of data loaded into a disk of the Elasticube Server. The average CPU usage during the load test was approximately 10 - 20 %.  This is spread acros s all of the distinct  CPU   cores. Performance Details  We used a tool called logz.io to analyze the server performance during the load test to aggregate logs into KPIs which we can analyze to determine the impact on the server and determine impact in production.  Here’s what those query performance results looked like across the hour-long test. To summarize, no query took longer than 3.1 seconds to return results to the web front end.     When it comes to the  server usage , we passed the test with flying colors as well.   Our  amazing   in - chip technology was on full display  -   we hosted  500 GB of data   without  utilizing   more than 128 GB of RAM . CPU utilization during query times never rose above  75 %  throughout the load test , and it a veraged less than 20 %.     Methodology We used a tool called  Load Impact  to create artificial users that log in and interact with dashboards to mimic production. That includes the following types of actions in Sisense:  Loading a dashboard with nine widgets Changing filter from one account to another and from one year to two years Filtering by clicking on context from one chart to control the others Drilling from country town to region - level data Downloading a .csv of the information in a Sisense widget Switch the dashboard, and repeat all steps above.   The two different user types (scenarios 1 and 2 below) performed the same steps. One group, however, had a where clause appended to all their queries to limit their view to one out of the seven customer accounts. This simulates the external, OEM use case for deploying to clients to view your dashboards. Here is a visualization describing the usage pattern over the timeframe. Across the two hours on the x-axis, the number of virtual users (VUs) is displayed on the y-axis. As you can see, the number of users ramped up for 50 minutes, remained steady for 10 minutes, and then did the same thing during the second hour.     The concurrent number of queries over the two-hour test increased throughout testing, as shown below. In Sisense, concurrency represents two or more users initiating a query within the same millisecond.   Data Details The data represented one billion purchases on a website, each with its own unique transaction ID. The purchases were split into three categories - planes, trains, and automobiles. Furthermore, the analysts wanted to kick the tires on Sisense’s ability to join large tables on demand. On user request, a three million record dimension table would join with that one billion record fact table to provide revenues from the fact table grouped by origin/destination combinations, contained in the dimension table.    The Elasticube looked like this:     Dashboard Details At the end of the day, the client wanted dashboards that tracked revenues, bookings, and average revenues per booking across time, client types, and fee types.  Here's one of the dashboards used during the testing:  

      Community_Admin
      Community_AdminPosted 1 year ago • Last reply 11 months ago
      1
               
    • Blog banner
      • News & UpdatesChevronRightIcon

      New academy content for administrators!

                                                                                       

      New academy content for administrators! We are pleased to announce the launch of 45 ALL-NEW COURSES that are AVAILABLE NOW for Administrators! These courses will help Admins of all skill levels by expanding their knowledge, providing hands-on opportunities, and covering all of our LATEST features and best practices (approximately 6 to 7 hours of content and hands-on practice). Our new courses are based on brand-new data and assets, divided into microlearning units. They are interactive and accessible! ( yes, yes, we finally have captions! ) To get access to the new Administrators learning path, CLICK HERE and then click on the blue Get Started button to register. If you are new to the Sisense Academy, I encourage you to make an account and sign up for courses based on your role. This is just the beginning of new content releases in Sisense Academy as we are working hard behind the scenes on the next set, and we look forward to sharing more with you soon! This is a continuation of the Academy Content Refresh. During January 2025, we launched 25 ALL-NEW COURSES that are AVAILABLE NOW for Data Designers, and during March 2025, we launched 15 ALL-NEW COURSES that are AVAILABLE NOW for Dashboards Designers. I hope to see you all in the Academy!

      iyyar_sg
      iyyar_sgPosted 1 year ago
      0
               
    • Blog banner
      • News & UpdatesChevronRightIcon

      Data prep essentials for AI-driven analytics - part 3

                               

      This is Part 3 of a multi-part series about Data Preparation for AI-driven Analytics.  We can agree that it's been said enough that data quality is important. And we don’t need to explain to you why feeding your AI model poor-quality training data, and then validating it with more poor-quality data, is a bad idea. What matters is knowing how to spot common data issues, how to fix them, and how to prevent them from happening again. Preparing data for AI teaching and validation processes requires addressing several common issues to ensure data quality and reliability In Part 1 and Part 2 of our Data Preparation Essentials series, we covered why clean, transformed, and enriched data is critical for AI success—and how proper training, testing, and refinement lead to better model accuracy. In this post, we’ll look at the most common data quality challenges and share practical steps to address them.  Data fields that are empty (NULL), missing or undefined, leading to gaps in analysis Duplicated data records that can skew results or inflate counts Values stored in the incorrect data types, causing errors in processing Unusually high or low values that may distort trends or averages Variations in how data is presented and formatted, reducing data reliability Whether you build or borrow your datasets, validation is necessary We’ll also provide some helpful code samples for both SQL and Python to help get you started. When data quality is a priority, AI-driven analytics perform better and deliver more reliable insights. Identify missing values to ensure unbiased analyses, accurate models, and maximum statistical power Missing values, often represented as NULLs, are a common issue in datasets. They can result from entry errors, incomplete data collection, or system failures. If a large portion of a dataset contains missing values, it can skew the results of statistical tests or machine learning algorithms, leading to misleading conclusions. Additionally, missing values complicate data preprocessing, often requiring extra steps to address them properly. Where to start: Assess the extent and pattern of missingnes s using visualizations (e.g., heatmaps, missing value matrices) and summary statistics to understand how much data is missing and whether it follows any patterns. Choose an appropriate handling strategy , depending on the context, to remove, impute, or flag values Document your approach to handling missing data to ensure transparency and reproducibility in analysis or modeling. The simplest approach is to run a query to identify where there are missing (NULL) values. You can then replace each identified NULL with a single value. Depending on the type of field, you can replace strings with specific text, numbers with 0 or another single value, and dates with the current date or the duplicate creation date for a given entry.  In some cases, when N/A is a product of a faulty data copy/creation process, you can use mechanisms like JOIN or LOOKUP to retrieve missing values from your source systems. After handling missing or default values, it’s important to check how common they are in a given column. If a large percentage of the values—say, 30% or more—are missing or set to a default like 0, the column may be too statistically skewed to be useful for AI or analytics. Running a simple query to calculate this percentage can help you decide whether the column is a good candidate for modeling. Dedupe datasets to ensure accurate counts, achieve unbiased summaries, and avoid overfitting your models Duplicates are unintended multiple entries of the same data point in a dataset. They can arise from data entry errors, merging datasets without proper checks, or system glitches. Datasets that contain multiple identical records can artificially inflate totals, distort summary statistics, and even lead to overfitting in machine learning models. Duplicates also pose problems during data integration, where unique identifiers are essential for accurately merging or joining records. Where to start: Identify and review duplicates using tools to detect and investigate repeated records. Remove or consolidate duplicates by dropping exact matches or merging partial ones with grouping and aggregation. Since the duplicate rows are identical, don’t stress about which one to keep — use MIN, ROW_NUMBER, or drop_duplicates() to your advantage! Prevent duplicates at the source through validation rules, unique constraints, or deduplication in data pipelines. Correcting data types can reduce errors in data processing, analysis, and visualization Incorrect data types occur when data is ingested and stored in a format that does not match its intended use, caused by improper data entry, incorrect data import settings, or lack of data validation. Common examples are dates stored as strings or numerical values stored as text.  These mismatches can cause issues, such as errors when performing calculations or unexpected results during analysis. They can also slow down database operations and data processing, leading to inefficiencies and higher computational costs. Where to start: Audit and validate data types using tools or code to ensure each column matches expected formats. Convert columns to the correct types with functions like astype() or pd.to_datetime() while handling errors. Standardize data entry and ingestion to prevent incorrect types from entering the dataset in the first place. Effectively managing outliers can lead to cleaner data and more reliable outcomes Outliers are data points that differ significantly from the rest of a dataset. They can occur naturally due to normal variability, or they may result from errors in data collection or entry, like measurement mistakes or incorrect input. Even a single outlier can have a large impact. It can distort key metrics like the mean and standard deviation, which may lead to misleading conclusions. Outliers can complicate key steps in data preparation, such as normalization, scaling, and feature engineering. If left unaddressed, they can distort the range of values, reduce the effectiveness of algorithms like k-means or linear regression, and lead to biased or unstable model performance. Where to start: Detect outliers using statistical methods like IQR, Z-scores, or visual tools such as box plots and scatter plots. Handle outliers based on context by removing, capping, transforming, or treating them as a separate category. Validate and document your approach to ensure transparency and account for whether outliers are errors or meaningful data. Create consistent formatting to make aggregation and analysis more accurate Inconsistent formatting happens when the same type of data is represented in different ways within a dataset. Common examples include mismatched date formats, inconsistent capitalization, or unexpected special characters. These types of inconsistencies seem trivial but make it harder to analyze or combine data accurately and often lead to errors or extra cleanup work. It can also disrupt data integration processes, where consistent formatting is essential for correctly merging or joining datasets. Where to start: Audit your data fields to identify inconsistent formats , so you know exactly what needs to be fixed and where issues exist. Define and document standard formats for each data type , ensuring consistency across your dataset and setting clear rules for future data entries. Create and apply transformation rules to standardize values , enabling reliable sorting, filtering, and AI-ready analysis. Build or borrow your datasets, but always validate If you’re creating your own dataset, everything discussed in this blog post—handling NULLs, deduplication, correcting data types, managing outliers, and ensuring consistency—applies from start to finish. You're responsible not just for the structure of your data but also for its completeness and integrity.  On the other hand, using a pre-existing dataset can save time and reduce initial effort, especially if it comes from a trusted source or has been curated for similar AI or analytics use cases. That said, whether you build or borrow, validation is essential. Remember to make sure to separate your testing datasets and validation datasets! Depending on your project, sourcing data may get you moving faster, but public datasets can still contain bias, outdated records, or inconsistent formats. If you're sourcing data externally: Look for accompanying documentation, licensing details, and data dictionaries that clarify how the data was collected and maintained Use profiling tools to understand the shape and distribution of the data Always run checks for missing values, unexpected types, or anomalies before feeding it into an AI model. Even “clean” data deserves a second look—assume nothing, validate everything. When it comes to tooling, there’s no single solution, but there are clear patterns. The key is consistency. Pick tools that help you catch problems early, document fixes, and apply the same rules across your data pipeline.  Core data cleansing can be achieved using flexible, low-level options like SQL and Python (especially with libraries like Pandas and NumPy)  Need to validate? Use tools like Great Expectations, Soda, and Pandera to help you define and enforce data quality rules Store and govern data using modern warehouses like Snowflake, BigQuery, and Delta Lake support schema validation and versioning out of the box Download code samples for all the steps above here. Samples are provided in both SQL and Python. Ensuring your data is AI-ready means more than just removing NULLs or fixing the occasional typo. It requires a consistent, structured approach to cleaning and validating your data. There’s a reason these are considered “common problems”—any organization working with data will run into them sooner or later, and not always because of manual errors. In many cases, these issues arise from changes in upstream systems, unanticipated dependencies, or well-intentioned updates that have unintended consequences. Someone shuts off a system without realizing it feeds other processes. Someone makes a formatting change that breaks your formulas. It happens. Proactively preparing your data helps reduce friction later in the AI development pipeline: Audit your datasets regularly Apply consistent formattin g and business logic rules Use validation queries and basic data profiling techniques Standardize inputs and create clear documentation While having the right monitoring in place helps, the reality is that many problems are still flagged by humans first—someone noticing that “something feels off.” Even with the best preparation, data issues will still happen. That’s why it’s so important to know where to look and what to look for: Know where issues are most likely to crop up (e.g., manual entry fields, API feeds, third-party integrations) Set up anomaly detection or alerts around critical metrics Build a habit of root cause analysis —don’t just fix symptoms Use automated checks for common failure points Data prep might not be the flashiest part of the AI workflow, but it's the foundation on which everything else is built. Your future AI models—and your future self—will thank you.

      Mia Isaacson
      Mia IsaacsonPosted 1 year ago
      0
               
      • Sisense AdministrationChevronRightIcon

      Update and add new Highcharts modules for use in Sisense plugins

                                                                                                                       

      Update and add new Highcharts modules for use in Sisense plugins The JavaScript library framework Highcharts is natively included in Sisense and is utilized in many native Sisense widgets as well as in numerous Sisense plugins. Although Sisense typically does not alter the Sisense Highcharts library version with every release, the versions of Highcharts included in Sisense may change when upgrading to a new major version release. Highcharts can load additional chart types and other types of functionality via JS module files that contain code-adding features such as additional chart types, which can be used within plugins along with additional code to create additional widget types. If a plugin utilizes a Highcharts module, you can source the module directly in the "plugin.json" file's source parameter, as shown in this example:   "source": [ "HighchartModule.js", ],   To determine the current Highcharts version being used in your Sisense version, you can use the "Highcharts" command in the web console while viewing any page on your Sisense server. After identifying the current Highcharts version, you can find the corresponding module hosted on a Highcharts code hosting website using the following URL format: https://cdn.jsdelivr.net/npm/highcharts@${Highcharts_Version}/modules/${module_name}.js For example: https://cdn.jsdelivr.net/npm/highcharts@10.3.3/modules/heatmap.js You can save this module and upload it to the plugin folder or replace the older module JS file simply by copying and pasting the code directly. Be sure to update the "plugin.json" file to point to the new module file if the file name has changed or if this is the first time the module is included. Simply sourcing the module file in the "plugin.json" file is sufficient to load the module into Highcharts; no further code is required to load the module.

      Jeremy Friedel
      Jeremy FriedelPosted 2 years ago • Last reply 1 year ago
      2