Best Practices | Sisense Community

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

Categories

MoreDiscussions

Best Practices | Sisense Community

Knowledge Base Docs

Best Practices

Created Apr 15, 2026

2 members

21 discussions

Sisense recommended Best Practices

Best Practices
Understanding custom code tables: why “infer from notebook” fails and when to avoid it [Linux]
Step-by-step guide How custom code tables work (high-level) When an ElastiCube build runs a Custom Code Table: Sisense executes the notebook. The notebook must return a pandas DataFrame at the end of execution. Sisense temporarily serializes that DataFrame to an internal CSV file. The CSV is ingested into the ElastiCube. The temporary file is deleted after the build completes. Important: Regardless of configuration, only the returned DataFrame is ingested. Displaying a DataFrame in the notebook UI does not load data into the cube. Option 1: “Infer from Notebook” (schema inference) What it does Runs the notebook. Reads the returned DataFrame. Automatically infers column names and data types. Saves the inferred schema to the table definition. This is intended to simplify setup by avoiding manual schema definition. Why it can fail: Schema inference is fragile and commonly fails with: Mixed data types in a column Null-heavy columns Date / datetime fields Large datasets Nested or irregular JSON structures Failures typically surface as build-time errors, such as: NPE in the guess column type CSV connector errors during schema guessing Although these appear as ingestion errors, they occur before ingestion, during schema inference. When to use Prototyping Small, clean, well-typed datasets Early development only Option 2: File-based output (recommended for production) What it does The notebook explicitly writes a file (CSV, Parquet, etc.) to: /opt/sisense/storage/notebooks/output/ The Custom Code Table is created to read from that file. The schema is fixed and deterministic. Why this works reliably Removes automatic schema guessing Ensures consistent data types Matches how most production-grade pipelines operate Example (Python code) # Python output_path = "/opt/sisense/storage/notebooks/output/my_data.csv" df.to_csv(output_path, index=False) Note: Even in this approach, Sisense still ingests data via an internal CSV — the difference is that the schema is no longer inferred from a live DataFrame. When to use Production deployments APIs and external data sources Large or complex datasets Any scenario where inference errors occur Common misunderstanding: notebook “test” or preview cells Developers often add cells that display a DataFrame for validation during development. While useful for debugging, these cells: Only affects the Jupyter UI Do not impact ElastiCube ingestion Are ignored during the build process During builds: Sisense may ignore designated dev/test cells Sisense injects its own cells for parameters and final serialization Only the final returned DataFrame (or its serialized output) is ingested. Conclusion Custom Code Tables rely on a single ingestion pipeline: a returned pandas DataFrame that is serialized and loaded during the build. The Infer from Notebook option affects schema discovery, not ingestion, and can fail with real-world data. Writing a file and using it as the table source removes schema inference and provides the most stable, production-ready configuration. References / related content Custom code for ElastiCube builds https://docs.sisense.com/main/SisenseLinux/transforming-data-with-custom-code.htm Community discussion: Notebook output DataFrame behavior https://community.sisense.com/discussions/build_analytics/notebook---output-data-frame-to-be-a-selectable-option-in-cube/20266 Sisense Linux data modeling best practices https://docs.sisense.com/main/SisenseLinux/data-model-building-practices.htm
CKenningtonPosted 4 months ago
0
Best Practices
Remove Filter statement field in PDF file [Linux]
When the user exports the dashboard in PDF, the Filter statement field appears and it’s empty if filter relations AND/OR were not used. L2025.1 and higher Step-by-Step Guide: As an Admin user, go to the Admin Tab App Configuration Feature Management Filters Filter Relationship → Toggle off: Save Once you disable it, the Filter statement field will disappear during exporting: Conclusion The steps above describe how to remove the Filter statement field in the PDF export file. 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.
Evgen CherninPosted 8 months ago
0
Best Practices
Preventing and understanding custom table build failures [Linux]
Step-by-Step Guide: Part 1: Best Practices to Prevent Build Failures When changes are made to upstream source tables in your external database, you must manually refresh the schemas in the Sisense model: In the Data Model Editor, click the three-dot menu next to the table name. Select "Refresh Table Schema". This ensures Sisense recognizes new, removed, or renamed columns and can properly align them during the build process. Re-Open and Save Downstream Custom Tables. If any custom tables depend on source tables or other custom tables that have changed: In your Sisense data model, open the affected custom table in Edit & Preview mode. Confirm the SQL still parses correctly. Click Save to trigger a fresh internal validation of its dependencies. Even if no changes are made, re-saving ensures that Sisense re-parses the logic and resolves dependencies correctly in preparation for the next build. These two steps should always be performed after any upstream changes, especially in complex models where custom tables are chained together. Part 2: Understanding Encoded Field Names in Error Messages Sisense uses an internal system to encode complex column paths for processing. This encoding is what causes confusing references in error messages. For example: acq.acurrent.quarter may appear in an error message as acq.acurrentXwAaquarter aQuarters.start.date.int may become aQuarters.aquarterXwAastartXwAadateXwAaint What is XwAa? This is Sisense’s internal way of flattening nested column references or handling special characters (like dots or spaces) during processing. These encoded column paths: Do not appear in the schema browser or field list Are not searchable in the UI Exist only in internal SQL and error logs during build-time parsing If you encounter these references, they usually point to a column or alias that either: Was deleted or renamed in an upstream table Is being referenced incorrectly in a downstream custom table Understanding these encoded names can help you trace the true origin of the issue, even if the field name is not directly visible in the current model. Conclusion Custom table build failures in Sisense for Linux often arise from stale or broken references caused by upstream changes. These failures are preventable with two simple practices: Refresh the schema of source tables after any external changes. Re-open and save dependent custom tables to trigger revalidation. And when errors reference unfamiliar encoded field names, remember: these are internal representations of previously valid (but now broken) field paths. Being aware of both the prevention steps and how Sisense represents internal SQL references will help you diagnose and resolve these issues much more effectively. References/Related Content: https://docs.sisense.com/main/SisenseLinux/editing-sql-statements.htm https://docs.sisense.com/main/SisenseLinux/managing-tables-and-columns.htm https://community.sisense.com/kb/troubleshooting/troubleshooting-silent-table-list-failures-in-live-models-dbt-and-external-schem/27916
CKenningtonPosted 8 months ago
0
Best Practices
Understanding NULL handling in Sisense [Linux-Windows]
What Is a NULL Value? A NULL value represents missing, unknown, or undefined data. In Sisense, properly handling NULLs is essential for accurate reporting and analysis. Note : Sisense’s behavior around NULL values may differ between Linux, Windows, and may change across releases. Always verify with your version’s documentation and release notes. Key Concepts of NULL Handling in Sisense 1. Aggregation of NULL Values SUM(NULL) = No Results When aggregating (e.g., with SUM), Sisense treats NULL as unknown—not zero. This is a critical distinction in data analysis. Example: [1, -1] → SUM = 0 [NULL, NULL] → SUM = NULL (“No Results” in some Sisense widgets) SUM(NULL) + 1 = No Results (Unknown + Constant) Adding a constant to a NULL (e.g., SUM(column_name) + 1 ) produces NULL (“No Results”). This reflects standard SQL behavior and is explicitly mentioned in Sisense’s documentation. 2. Handling NULL Values in Filters Sisense may exclude or ignore NULL values when filters are applied—especially with older versions or certain widget types. This can cause inconsistencies when trying to display or filter for blank/“N/A” data. Example: If a filter is set for non-NULL values, NULLs may be omitted from visuals, potentially hiding data you expect to see. Troubleshooting: If you need to include/exclude NULLs in filter results, check your filter’s logic, test in different widgets, and review your platform’s current documentation. 3. Pivot Tables and Scripting for NULL Handling Pivot Tables in Sisense can be customized via scripting to control how NULLs are displayed—for example, converting NULLs to 0 or a blank. Sample Script: if (row['column_name'] == null) { row['column_name'] = 0; // Replace NULL with 0 } This technique is widely used to improve readability and data interpretation. 4. SQL and NULL Values (Standard SQL) Replace NULL with a chosen value (e.g., 0 or ' N/A ')—prefer a custom column, not a custom table. Custom Column (recommended) Use one of these expressions when adding a Custom Column: Option A — COALESCE (preferred) COALESCE([column_name], 0) Option B — CASE CASE WHEN [column_name] IS NULL THEN 0 ELSE [column_name] END This creates a new column that returns 0 instead of NULL. Do not use SELECT ... FROM ... here—that would create a custom table, not a column. Direct SQL (custom table or live query) If you’re intentionally writing a query: SELECT COALESCE(column_name, 0) AS column_name_no_nulls FROM table_name; Text fields For text, replace with an empty string or label: COALESCE([text_col], '') -- or COALESCE([text_col], 'N/A') After adding a custom column in ElastiCube models, rebuild/publish so widgets can use it. 5. Behavior of NULLs in Queries (Advanced/Optimization) The way NULLs are returned may vary if query optimizations (like the “WHERE optimizer”) are enabled. With optimizer ON, queries may return rows containing NULLs. With optimizer OFF, these rows may be omitted. Explicitly check for NULLs in your query if needed: SELECT * FROM table_name WHERE column_name IS NULL Source: Sisense Community Article – Null Handling in Sisense Best Practices for Handling NULLs in Sisense Use COALESCE in SQL: Replace NULLs with a default value for easier aggregation and analysis. Customize Pivot Table Displays: Use JavaScript scripting to show NULLs as zeros or blanks for clarity. Test Filters Thoroughly: Always validate how your filters behave with NULLs in different widgets. Explicit NULL Checks: Use IS NULL or IS NOT NULL in queries for precise control over data returned. Troubleshooting: Common Issues with NULLs in Sisense Widgets show “No Results” unexpectedly: Check for NULLs in source data; consider using COALESCE or scripts. Filters don’t show N/A or blank values: Some widgets or older Sisense versions may ignore NULLs. Test in Pivot Table, Table, and Indicator widgets. Aggregate calculations appear incorrect: Review how NULLs are treated—SUM(NULL) is not zero! Behavior changed after upgrade: Review your Sisense release notes and documentation for any NULL-handling updates. Glossary NULL: A value indicating “unknown” or “missing data.” COALESCE: A SQL function that returns the first non-NULL value in a list. Pivot Table: A Sisense widget that can be customized to handle NULLs via scripting. References & Source Attribution Sisense Official Documentation: Handling NULL Values in Sisense (Linux) Direct source for aggregation, arithmetic, and filtering behavior. Sisense Community Article: Null Handling in Sisense (FAQ) Source for scripting, filters, optimizer notes, and user-reported behavior. General SQL Best Practices: SQL COALESCE Function For SQL syntax and examples. By understanding how Sisense handles NULL values and utilizing best practices, you can ensure your dashboards and reports display data accurately and consistently. This knowledge is especially crucial when performing aggregations, filtering, and working with Pivot Tables. ======= 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.
Vicki786Posted 8 months ago
0
Best Practices
Understanding Sisense REST API request rate limits
Understanding Sisense REST API request rate limits Introduction This article provides guidance on handling request rate limits when using the Sisense REST API. Users often need to perform operations such as creating multiple users or assigning permissions, which raises concerns about how many requests the Sisense API can handle concurrently without issue. Since Sisense deployments can vary significantly based on infrastructure, usage, and configuration, understanding how to manage request rates effectively is key to ensuring system stability and performance. Understanding API Rate limits Sisense does not publicly define strict rate limits (e.g., a maximum number of requests per second) for its REST API. However, it would be best to proceed with care during bulk operations, particularly when using write-heavy or resource-intensive endpoints—to help prevent performance issues or API errors. Important: The guidance provided in this article is based on practical experience. It is not an official Sisense-enforced limit, and actual safe limits may vary per environment. Recommended practices 1. Estimate Safe Throughput As a general guideline: Write-heavy endpoints (e.g., /users , /elasticubes/security ) can typically support a rate of 5–10 requests per second in well-provisioned environments. Higher volumes are recommended to be batched , and requests spaced with short delays (e.g., 100–200ms intervals) to prevent overloading. NOTE: Not all endpoints behave the same. Operations involving Elasticube builds or data model changes are usually more resource-intensive than operations on users. 2. Conduct controlled testing Each Sisense environment is unique in its configuration and data workload. Before running any large-scale API operations: Simulate your use case in a staging or low-traffic environment. Monitor system behavior : CPU usage, memory, API latency, and error responses. Adjust your API pacing based on performance indicators. 3. Implement error handling and retry logic Common errors from overloading the API include: 429 Too Many Requests : Indicates that the system is receiving more requests than it can handle. 500 Internal Server Error / 504 Gateway Timeout : Can result from system resource exhaustion. To manage this: Implement exponential backoff when retrying failed requests. See below reference for more details. Log and analyze errors to detect patterns in overload or timeout conditions. Ensure your automation scripts or middleware can gracefully pause and resume batches as needed. 4. Monitor and adjust dynamically During bulk operations or automation runs, continuously monitor: API response times Error rates System load (CPU, memory, disk I/O) Based on these metrics, dynamically adjust the number of concurrent requests or introduce delays to stay within safe limits. Applicability across Sisense REST APIs While the 5–10 requests per second benchmark is a helpful generalization, not all endpoints share the same performance characteristics : API Type Safe Practices /users, /groups Typically safe for batch creation with moderate throttling /elasticubes, /datamodels More sensitive; should be throttled more conservatively /dashboards, /widgets Medium intensity; test pacing based on object size Deletion Heavy operation due to cascading deletion of associated objects Build/refresh endpoints High resource load; avoid parallel execution Always test specific endpoint behavior before bulk automation in production environments. Conclusion Sisense's REST API is powerful and flexible, but it’s essential to approach high-volume operations with caution. While Sisense does not enforce a fixed request rate limit, following best practices, such as limiting throughput, monitoring, and error handling, ensures robust and stable API usage. By conducting tests in your environment and adjusting based on real-world behavior, you can confidently scale your integration or automation safely and efficiently. References / related content Sisense Community - API Rate Limiting Clarification Sisense REST API Documentation Effective API Querying: Best Practices and Recommendations exponential backoff HPA was introduced to help with scaling challenges 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
Vicki786Posted 1 year ago
0
Best Practices
Adding custom images to Sisense dashboards: best practices and guidelines

Adding custom images to Sisense dashboards: best practices and guidelines Sisense allows you to add your images to dashboards. For example, these pictures can be added as the custom logo on the dashboard or to represent some data like legend or description. There are two folders in Sisense where publicly available files can be placed. These are the following folders (let’s call them root folder): branding; plugins. Use File Manager to get to these folders and place your images. For better managing these files I recommend creating a new folder. Let’s call it “ resources ”. Place a new picture “ myImage.png “ into the folder we have just created. Now, your picture will be accessible on the next URL (depending on the root folder): {sisenseUrl}/branding/resources/myImage.png; {sisenseUrl}/plugins/resources/myImage.png; Since every change in the directory “plugins” causes plugins rebuild, it is recommeded to store your resources in the folder ‘branding’. Also, many images in the folder ‘plugins’ will increase time of the plugins rebuild. Unfortunately, there is no out-of-the-box solution that restricts authenticated users' access to these files. If you need to restrict access to your resources for not authenticated users, please, contact support for reviewing the case. Using these paths you can store images that will be later used by the widgets (for example BloX, or RichText) to make your dashboards more interactive.
Sisense UserPosted 1 year ago
0
Best Practices
Leveraging Sisense Notebooks with Compose SDK

Leveraging Sisense Notebooks with Compose SDK In today’s developer ecosystem, delivering a tailored creator experience is essential for success, especially when integrating analytics into customer-facing applications. Many existing solutions offer a generic, one-size-fits-all approach, typically centered around drag-and-drop interfaces. While these tools may be convenient, they often limit the depth of customization needed for unique business use cases. Additionally, platforms that offer more advanced capabilities usually require adopting proprietary syntax, which can drive up costs by necessitating specialized expertise. Sisense, however, provides a powerful code-first analytics solution that eliminates these barriers. It allows your data teams to leverage their existing skills—such as SQL, Python, and R—to create highly customized insights that align with your organization's specific needs, without needing proprietary languages or systems. In this article, we’ll explore how you can use SQL specifically to create custom datasets and charts, and then embed those visualizations into your web applications. This workflow emphasizes the creator experience for data teams, empowering them to build meaningful, business-specific analytics that enhances your product’s value. Building Custom Datasets with SQL Let’s dive into a specific use case. Assume you have a commerce table with two key columns: `transaction_amount` and `transaction_status`. You need to analyze revenue, categorizing it by transaction type (e.g., paid, refunded, or canceled). This provides insight into gross revenue versus potential revenue lost to refunds or cancellations. Below is the SQL query used to create a custom dataset for this scenario: ( Dataset Git Repo ) ( Data Model Repo ) SELECT TO_CHAR(DATE_TRUNC('month', transaction_date), 'YYYY-MM') AS "Date", transaction_id, SUM(CASE WHEN transaction_status = 'Paid' THEN transaction_amount ELSE 0 END) AS "Actual Revenue", SUM(CASE WHEN transaction_status IN ('Refunded', 'Cancelled') THEN transaction_amount ELSE 0 END) AS "Potential Revenue" FROM commerce GROUP BY DATE_TRUNC('month', transaction_date), transaction_id; This query creates a monthly summary of actual revenue and potential revenue lost due to refunds or cancellations. After running the query, you can preview the output in Sisense and immediately take action. Integrating Custom Data into Fusion Once your custom table is generated, you have several options for incorporating it into your analytics workflow: Adding Notebooks Charts to Dashboards 1. Integrate within the Semantic Model: The SQL table can be added to Sisense’s semantic layer, allowing you to build charts and dashboards on top of it using Fusion Dashboards or Compose SDK. 2. Build Charts for Integration : You can also directly build charts based on this table and pass them to your frontend team for integration into customer-facing applications. Streamlining Developer Workflows with Compose SDK Once your data team has completed their SQL-based analysis and crafted custom datasets and charts, the true value lies in how effortlessly developers can integrate these insights into customer-facing applications. By publishing the dataset to the Fusion semantic model , developers can use Sisense’s command-line tools (like '@sisense/sdk-cli') to dynamically generate TypeScript representations of the dataset right within their IDE. This streamlined process ensures that the work done by analysts is directly accessible to developers, enhancing the builder experience by providing immediate access to the datasets. This integration allows developers to efficiently embed highly customized, meaningful analytics into the front end, ensuring that the insights are not only visually compelling but also tailored to the specific needs of the end users. Creating Custom Visualizations Once charts have been built in Sisense Notebooks and published to Fusion , developers can begin integrating them seamlessly into front-end web applications using the Compose SDK . This process allows developers to embed dynamic, SQL-powered visualizations directly into customer-facing apps. By leveraging the Compose SDK, developers can access the published charts, configure them for specific frontend needs, and ensure a consistent, interactive user experience. This workflow streamlines the integration of custom analytics into web apps, providing flexibility and efficiency for development teams of all varieties. This code snippet demonstrates how to integrate both a custom column chart and an existing dashboard widget into a React application using Sisense’s Compose SDK. The `ColumnChart` component displays actual and potential revenue by year, while the `DashboardWidget` component integrates a pre-existing Sisense dashboard into the application. DashboardWidget Sisense CLI import { ColumnChart, DashboardById, DashboardWidget } from '@sisense/sdk-ui'; import * as DM from "../notebooks-tutorial" import { measureFactory } from '@sisense/sdk-data'; function ComposeSDK() { return ( <> <ColumnChart dataSet={DM.DataSource} dataOptions={{ category: [DM.ActualVsPotential.transaction_date.Years], value: [ measureFactory.sum(DM.ActualVsPotential.actual_revenue, 'Actual Revenue'), measureFactory.sum(DM.ActualVsPotential.potential_revenue, 'Potential Revenue'), ], breakBy: [DM.commerce.age_range], }} styleOptions={{ height: 500, }} /> <DashboardWidget dashboardOid="66e8aa5e724a0b00338cbed9" widgetOid="66e8c716724a0b00338cbefc" /> </> ); } export default ComposeSDK; Conclusion: This code-first approach to analytics meets technical creators where they are, empowering data teams and developers alike. Whether your analysts are leveraging their existing skills in SQL through the powerful Notebooks environment or your developers are dynamically generating insights within their IDE using the Compose SDK , Sisense offers a seamless and collaborative experience. By enabling teams to work with familiar tools and environments, Sisense allows you to deliver powerful, tailored analytics that fit your organization’s unique needs. This fluid, creator-friendly workflow ensures that both data teams and developers can focus on building impactful insights without the friction of proprietary systems, enhancing the overall efficiency and creativity of your analytics solutions.
Sisense UserPosted 1 year ago
0
Best Practices
BI Solutions: Business Requirements Gathering
Business Requirements Gathering The Business requirements gathering step aims to identify the end-users key business requirements and KPIs to build customized dashboards that meet their needs. Well-defined requirements are the foundation for a clear, comprehensible dashboard, that enables the end-user to gain business insights. To help you get started, we've gathered a list of questions that will help you gather the information required for your project from your end users. Required Information - Questions List TIP : Just like a good story, requirements should answer all your important questions. Think about the What, When, Who, and How: Define the dashboard’s business need ● Who is going to use the dashboards? ● What are the dashboard business’ needs? (Summarize/ analyze/ monitor) ● When will the dashboard be used? How timely, must the data be? Describe success and set KPIs ● Describe success: what is your desired business result? ● What KPIs represent this business result? Identify cause and effect chain ● What behaviors or activities will drive desired business success? ● What are the expected intrinsic outcomes? Build dashboard hierarchy and KPI architecture ● What measures represent intrinsic outcomes (leading & lagging)? ● How would you describe it? Build dash hierarchy This list should help you define requirements for your dashboard that clearly visualize your business objectives. In addition, we've created a step-by-step process on how to gather the information you need. From planning and getting ready to conduct an information research session. To read further please refer to the "How to gather the information?" document attached to this article. Download Links: Business Requirements Gathering.doc
Community_AdminPosted 2 years ago
0
Best Practices
BI Solutions: High Level Design

Based on the business requirements summary you've created in the previous step, you can now design the high-level overview of your BI Solution. This step aims to translate the business strategy into operational terms and associate it with the required data. For that, we will use the Dashboard Planning Document. The document will assist you to define the business goals and objectives and break it down into specific KPIs and measures. Then, we will be able to link each measure to its relevant data and formula. The following template will assist you in planning your dashboard. You can download the template at the bottom of the document. Dashboard Hierarchy Creating a dashboard flow chart is recommended while planning any BI project. Dashboard Outline This section describes the dashboard objective, the different types of users that will be using the dashboards and the expected call to action, based on this dashboard. Business Objectives - Main Business Questions A Business Objective is a Sub-goals, the steps to achieve the main goals, Medium or small in size, Concrete Shorter term, SMART. For Example: Increase the number of qualified leads Reduce marketing cost Dashboard Mockup A freestyle sketch of the final dashboard, to illustrate the dashboard layout, the selected visualization for each KPI, and additional information such as filters, plugins, etc. KPIs Architecture Break each objective into KPIs and measures, and specify the formula and data tables that are required for achieving the KPIs. Key performance indicators - Business metrics which support decision making. KPIs are used to evaluate factors which are crucial to achieving the business objectives. Measures - Quantifiable values which can stand alone or when composed with other measures form KPIs. For Example: ElastiCube Design Maps, in detail, the data elements that are required for analyzing the above KPIs. This map will help you to plan the ElastiCube structure and connections between the data elements in your model Implementation Constraints: This is the place to mention any general constraints you have on your analysis and limitation in terms of the data model (such as data security, the frequency of use, special business logic, etc.)
Community_AdminPosted 4 years ago • Last reply 2 years ago
2
Best Practices
Planning, Executing, and Monitoring your Dashboard

Introduction The following article discusses a dashboard's (high-level) development cycle. It breaks the process into easy measurable steps that start from the initial KPI planning all the way to maintaining and adjusting your end product. Table of Contents Table of Contents Introduction Table of Contents Introduction toDashboards Dashboard Types The Dashboard Design Process Planning the Dashboard Requirements Gathering Functional Requirements Technical Requirements A Dashboard Mockup BI Solution High-Level Design Building a KPI Logic Structuring the Dashboard Widgets Planning the Data Model Structure Executing the Dashboard Design Delivering the Dashboard Performing a UAT Training the End-Users Sharing the Dashboard Monitoring the Dashboard Tracking the Usage of the Dashboard Creating a StakeholderFeedback Loop Adjusting the Dashboard Over Time Introduction to Dashboards A Business Intelligence (BI) Dashboard is a graphical visualization of analytical information to an end-user. The analytical information displayed represents the status of key performance indicators (KPIs) and other critical business metrics. Different dashboards are be exposed to different personas in the organization. Each dashboard should be designed according to its target audience and the decision(s) they can make based on it. Dashboard Types The industry divides "BI Dashboard" into four categories: Operational Dashboards focus on operational processes within an organization (e.g., a production process). The goal of such a dashboard would be to monitor and overlook a process. These reports are usually used by junior-level employees who make operational decisions. Analytical Dashboards c ontain a large amount of data and indicators that help analysts understand data - This includes identifying trends, comparing them with multiple variables, and creating predictions and target figures. These dashboards help analysts define the strategy of a company. Strategic Dashboards f ocus on long-term KPIs and high-level metrics. The upper management uses these dashboards to monitor the company's strategy. These dashboards have a high value, but in most cases, as standalone reports - Cannot help decision-making. Tactical Dashboards display the business/department KPIs and provide all data required to accelerate decision-making. These dashboards are u sed by mid-management and are the most common dashboards in the market. The Dashboard Design Process The high-level process of designing a dashboard contains four main phases: Planning the BI solution Executing the dashboard design Delivering the solution Monitoring & adjusting the dashboard Planning the Dashboard Planning the dashboard includes two main steps: Requirements Gathering Solution High-Level Design Requirements Gathering A practical and valuable dashboard requires planning. The information you should gather before designing a dashboard includes: Functional Requirements - Discussing the user case, business requirements, and involved users Technical Requirements - Discussing the data sources, structure, and security requirements A dashboard mockup - Showing the proposed endgame Functional Requirements The functional requirements include: The Dashboard's Objective - Describes a clear goal this dashboard addresses This may consist of a business question you wish to answer or a decision one should make based on its contents The Target Audience - The type of users who'll participate in the lifecycle of this dashboard: Decision Makers - Who defines the business requirements and questions? End Users - Who uses this dashboard? Beta Users - Who performs the User Acceptance Test (UAT)? Call to Action - The user activity that should take place based on this dashboard. Timelines - The time of when the dashboard has to be ready for UAT and a go-live date. Technical Requirements The technical requirements you should gather include: The KPI Architecture - A list of KPIs included in this dashboard A KPI Breakdown - How is each KPI calculated (specific data sources and formulas) Data Update Frequency - The frequency of which the data in this dashboard should update History Depth - The length of data history this dashboard should present Data Source Information - The list of data source(s) mentioned in the "KPI Breakdown" and how to connect to each of them Data Security Requirements - The data restrictions users/groups of users should have A Dashboard Mockup The mockup refers to the way the dashboard's viewer anticipates this dashboard should look like - Usually in the form of a graphical illustration. BI Solution High-Level Design A dashboard's "High-Level" design requires: Building a KPI logic Structuring the dashboard widgets Planning the data model structure Building a KPI Logic The starting point to planning a dashboard is gathering all required KPIs from the decision-makers. The KPI list may be lengthy, but don’t worry about it: Phase #1 - Build a Story Build a story based on the list of KPIs - To do that, ask the decision-makers what the process of making a decision - What factors are considered is? Where is the data located? Make them build a "flow-chart" for the decision-making process. Phase #2 - Define the First KPI Find out what is the most significant figure in this dashboard. This will usually be the "First KPI" (usually a business-critical value – Such as the “Total Revenue” or the “Outstanding Sales Amount”). Now, try to assess what value range is considered “Good” or “Bad” – You’ll later use this information to visualize the data (avoiding just showing a number and leaving an end-user clueless of its meaning) Phase #3 - The Next KPIs The next goal is to determine what the end-user would look at next based on either a “Good” or a “Bad” value of the first KPI. Repeat asking this same question as necessary until all scenarios are covered. Note that the KPI list may change during this process as the customer might have missed a KPI or had one that wasn’t necessary for the decision-making process. Phase #4 - Verify your Work Present the decision-maker with the flow-chart you've created - Make sure they could make the “Call for Action” decision off of it. Structuring the Dashboard Widgets Structuring the widgets refers to translating the "flow chart" into an intuitively usable dashboard mockup. A dashboard is constructed out of widgets (each covering one or more KPIs). As the customer wasn't limited on the number of KPIs covered in the dashboard, we'll have to: Translate the KPIs into widgets Categorize the widgets by their type Choose what widgets fit into the dashboard and which don't While translating KPIs into widgets, you may realize that the number of widgets exceeds Sisenes's best practices. In this case, assess each KPI's type - The three types of KPIs are: High-level figures such as a “Total Revenue” or a "Change Rate." Mid-level figures such as a “Revenue Breakdown" or a "Product Category Breakdown." Low-level figures such as an "Employee Expense Breakdown" or "Per-product Sales Breakdown." The high, medium, and low-level figures would usually correlate with the different hierarchies you see in the flow chart. The structuring flow should contain the following steps: Place “High-Level Figures” in the "flow chart" order These will allow the end-user to see their most influential figures in a single glance Next, according to the amount of data already in the dashboard, assess whether one (or more) “Mid-Level Figures” can be added As the “Low-Level Figures” aren’t crucial at first glance – Place them in a different dashboard accessible via an add-on (such as a Jump to Dashboard or an Accordion ) Planning the Data Model Structure As a BI database structure is different than a conventional database (i.e., facts and dimensions), it must be redesigned to meet the various business questions. The process of designing data models will be covered in a separate knowledgebase article. Executing the Dashboard Design Executing the dashboard design includes three repeating phases: Importing the data required for calculating a single KPI into the data model Building a widget to present that KPI in the dashboard Customizing the widget to convey a message best Delivering the Dashboard The process of delivering a dashboard to the end-users should include as many steps to drive adoption and useability as possible. These may include: Performing a User Acceptance Test (a.k.a. UAT) Training the end-users on how to use the dashboard Sharing the dashboard and allowing an open communication channel for feedback And more Performing a UAT As the name suggests, the UAT is conducted on the final version of the product by the end-users defined during the dashboard preparation phase. These usually include various stakeholders such as project sponsors, business owners, business analysts, etc.) The UAT's goal is to provide the final feedback before the dashboard releases. The feedback period is usually limited to a week or two, where the stakeholders operate and challenge the dashboard (and the data model behind it). There are two methods of performing a UAT: Providing a test document - allowing the users to follow a few predefined tests Allowing the end-users to "monkey test" the environment. All issues found are logged and may be fixed to generate a final dashboard version. Training the End-Users Employees will feel more confident about using the new software or technology if they’ve been involved in training before the new system goes live. Make sure to: Assess learning requirements - If people are unwilling or unable to use it, you’ll never be successful, even with the best system in place Develop a tailored plan - Be clear about what the business expects from the training and what the employee will gain from it - A system is only as good as the people who use it. Secure resources - Don’t forget practical parts of the new system, such as the suitable access, so that employees can learn the new system without any roadblocks in their way. It’s essential to ask for feedback from the end-users during the training. Knowing what areas users don’t feel adequately trained on will help mitigate the risk of implementation failing later. Sharing the Dashboard Finally, share the dashboard with all end-users. If this dashboard replaced a previous version or a different product - Allow a transition period However, do plan a firm date to decommission it Monitoring the Dashboard Monitoring the dashboard will be done by: Tracking the usage of the dashboard Creating a feedback loop with the end-users Adjusting the dashboard over time Tracking the Usage of the Dashboard Sisense offers Usage Analytics ( Link ) to track the performance and usage of dashboards. With Sisense Usage Analytics, you can better understand how users interact with Sisense dashboards and optimize the configuration accordingly. For example, you can understand which dashboards impact and how fast the dashboards load. Creating a Stakeholder Feedback Loop Communications are everything - Allow the end-users to operate their dashboards for a while before contacting them and asking for their feedback. When asking for feedback, focus on the following questions: How are you using the dashboard? How often are you accessing the dashboard? Are you able to answer your "Call to Action"? How can I make the dashboard more intuitive? Is information missing from the dashboard? Is there data you don't use in the dashboard? Guide the stakeholders to provide meaningful feedback rather than a general "I like it" or "I use it when I need it." Adjusting the Dashboard Over Time A dashboard does get old - Make sure to revisit it once every 6-12 months. Revisiting it may include major fixes (such as modifying the KPIs or widget types) or minor fixes (such as formatting and visualization).
Ophir_BuchmanPosted 4 years ago • Last reply 2 years ago
2