Using ComposeSDK Planning Documents: Guiding an AI Coding Assistant with a Written Planning Document From Zero to ComposeSDK describes building a ComposeSDK application one prompt at a time, and that approach scales well. Adding one page, one widget, one filter at a time, each described on its own and confirmed before moving to the next, works for a small dashboard and for a larger one, provided each addition is independent and the person directing the assistant is already thinking through the pieces one at a time. This article describes a different way of working with an AI coding assistant. It is not strictly better than the approach in that article, simply different. Rather than prompting through a ComposeSDK build step by step, the assistant drafts a written plan first. That plan gets revised over a few rounds while nothing has been built yet, and only then does the assistant implement most or all of it in one longer working session. It is a more involved process than the one in From Zero to ComposeSDK, worth using when enough of a project is already decided in advance that writing it down once is less effort than describing it prompt by prompt, not a step every ComposeSDK build needs. Any modern LLM based coding assistant can drive this workflow the same way it drives the one described in From Zero to ComposeSDK . It needs the same two capabilities, editing files in the project folder and running terminal commands. This article mostly describes Claude Code as an example, but nothing about a written planning document is specific to it, and the same steps apply with another agentic editor, a standalone CLI assistant, or a desktop app with terminal access. This article does not cover installing the editor, the assistant, Node, or ComposeSDK itself, and it assumes the setup from From Zero to ComposeSDK is already in place, a scaffolded React project with the ComposeSDK packages installed and a .env file holding the Sisense instance URL and API token. It builds on that setup rather than repeating it. A planning document does not remove the need to review the assistant's work. It moves most of that review earlier, into the document, before the assistant starts writing code against it, rather than after each small step. A plan reviewed carefully before implementation catches a wrong field name or a missing page as a one line edit. The same mistake caught after a long stretch of implementation can require changes in many different places, and costs considerably more time to fix. What goes Into the Planning Document A planning document for a ComposeSDK build works best as a plain markdown file kept in the project, for example plan.md in the project root, rather than something that only exists in the chat history. As a file on disk, it can be opened and edited directly, referenced again in a later session, and it survives a long session's context being condensed in a way that conversation history alone does not. The document does not need a fixed template, but it generally works better when it covers a few things beyond a page and widget list. What the application is for, who uses it, and what habit or decision it supports. Which ComposeSDK flavor the project uses, React, Angular, or Vue, since that decides the package names and component syntax everything else in the plan assumes. The data model involved, referencing the .ts file already generated by the ComposeSDK CLI, or naming the data source if it still needs generating, along with why the fields involved matter to that audience, not just their names. Each page or view and its widgets, specific enough to build from, naming the chart type, the dimensions and measures, and any filters. Interactivity between widgets or pages, such as a filter or a click on one page affecting another. Layout and visual style, to whatever level of detail is already decided, colors, branding, density. Where the Sisense URL and token is and how the assistant checks its own connection without viewing or saving the authentication token, covered in its own section below. A milestone checklist, ordered the way the build should proceed, written as markdown checkboxes so the assistant can mark each one complete as it finishes. Anything explicitly out of scope, so the assistant does not add it unasked while working through a long stretch unsupervised. The checklist carries the most weight during implementation. A long LLM working session eventually has its earlier history summarized, and a agent's summarization keeps only a handful of the most recently read files in full alongside the summary. A checklist file the assistant is instructed to re-open at the start of each milestone stays accurate regardless of how much of the conversation itself has been condensed, because the current state of the build lives in the file rather than in memory of the conversation. Drafting the plan The first cycle is a conversation, not a single prompt. Describing the project and asking for a draft is enough to start. The prompts throughout this article are rough examples of the general tone and type of instruction, not meant to be copied directly. The right wording depends on the specific ComposeSDK application being built. Draft a planning document for a new React ComposeSDK application in this folder, save it as plan.md. It's for the regional sales team, replacing three spreadsheets they currently cross-reference by hand before the weekly pipeline review, built on the Sample ECommerce data model, which mirrors what's in those spreadsheets. Use ComposeSDK's ExecuteQuery function to look at the actual values in a column if that would help, not just the field names in the schema file. The token for authentication is in .env. Cover the purpose, why the data matters to this audience, each page and its filters, any interactivity between pages, a rough visual style, and a milestone checklist. List anything you're unsure of as open questions in its own section rather than guessing. That last instruction matters. An assistant asked to draft a plan will otherwise fill a gap with a guess that sounds reasonable rather than flagging it, and a guess buried in a paragraph of prose is easy to miss on a first read. A dedicated "Open questions" section in the draft is easy to scan and resolve before moving on. Revising the plan across cycles The draft is rarely final on the first pass. Revising it happens either by editing the markdown file directly, or by describing the change and letting the assistant update the file. In plan.md, change the regional breakdown page to a map visualization instead of a bar chart, and add a country filter UI that applies across all pages. Update the milestone checklist to match. Either editing style works, and most planning sessions mix both, a person adjusting a sentence directly while asking the assistant to work out the consequences elsewhere in the document, such as keeping the checklist in sync with a changed page list. As many cycles as needed happen before implementation starts. Nothing has been built yet, so a revision at this stage costs a paragraph, not a refactor. Keeping the connection working while the build runs The plan should note where the Sisense URL and token live, .env , and that the assistant's own read access to it is denied, the setup already covered in From Zero to ComposeSDK. That protection does not need re-explaining here, the plan only needs to point at it. What is worth adding for a longer, less supervised run is two different checks, since they answer different questions. Rotating the token or changing the URL is the only thing that actually requires re-testing whether the assistant can still reach Sisense at all. Reusing the same ComposeSDK CLI command already used to generate the data model file, pointed at a throwaway output path, is a reasonable way to confirm that without the assistant ever seeing the token value, since the script reads .env at run time on its own rather than through a tool call the assistant's file permissions would block. // scripts/check-credentials.mjs // Confirms Sisense credentials still authenticate, without printing // the token. Run with: node --env-file=.env scripts/check-credentials.mjs import { execFileSync } from 'node:child_process'; const url = process.env.VITE_SISENSE_URL; const token = process.env.VITE_SISENSE_TOKEN; try { execFileSync( 'npx', [ '@sisense/sdk-cli', 'get-data-model', '--url', url, '--token', token, '--dataSource', 'Sample ECommerce', '--output', 'scratch/credential-check.ts', ], { stdio: 'ignore' }, ); console.log('Sisense credentials OK'); } catch { console.log('Sisense credential check FAILED'); } This is worth running once after setup, and again only if the plan notes that .env has changed. Running it after an ordinary milestone, like adding a widget, confirms nothing new, since nothing about the credentials changed either. This is for the assistant to run on its own, a person does not need to run it by hand. What the assistant will almost certainly check on its own, once there is a widget to look at, is whether it renders the way the plan describes, and that is a visual check, not a credential check. If the session has a browser automation tool connected, a Playwright MCP server is a common example, the assistant can open the running dev server itself, take a screenshot, and confirm the new chart or page looks right. Asked to verify a milestone and given a way to see the running app, most assistants will reach for exactly this on their own, without needing the mechanism spelled out. Without a connected browser tool, this check still means a person glancing at the running app in a browser, the same as the smoke test described in From Zero to ComposeSDK. If the assistant asks partway through to install a browser automation tool, whether as a yes or no prompt or a plain request, it is usually worth approving. Iterative development goes far better when the assistant can see what its own code produces instead of just describing it. The plan's connection section can state this plainly, without prescribing how. URL and token in .env, read access denied per project settings. Re-run scripts/check-credentials.mjs only if these values change. After each milestone, confirm the change actually renders correctly in the browser. Choosing a permission mode for the implementation run Claude Code, used here as the concrete example, cycles through a few permission modes with Shift+Tab, and the mode in use during implementation determines how often the assistant stops to ask before acting. Manual (the default) asks before every file edit and most shell commands. It suits the planning cycles above, where little is being written yet, but is not practical for a long implementation run, since it interrupts constantly. Accept Edits auto-approves file edits and common filesystem commands, while still asking before other shell commands, such as installing a package or running a build, unless those have already been allow-listed. It is a reasonable default for working through a reviewed plan. Code changes stop interrupting, while a command run for the first time still gets a look. Auto goes further, approving tool calls generally with a background safety check evaluating each action against what was asked, rather than a person reviewing each one. It suits a long stretch of implementation against a plan that has already been reviewed carefully, since there are fewer opportunities to catch a problem as it happens. Bypass Permissions ( --dangerously-skip-permissions at startup) skips prompts almost entirely. It is documented as intended for use inside a container or VM the assistant cannot otherwise damage, not on a developer's own machine. Since the setup this article builds on keeps a live Sisense token in .env on that same machine, this mode is out of scope here. Other LLM's have very similar permission modes. Whichever mode is active, deny rules are checked before any mode grants approval, so the .env protection from From Zero to ComposeSDK stays in effect through Accept Edits and Auto mode as well. Commands already known to be safe and expected by the plan, running the dev server, running tests, regenerating the data model, can be allow-listed directly in .claude/settings.json (or equivalent for your LLM) so they stop prompting even once, while everything else continues to ask. { "permissions": { "allow": [ "Bash(npm run *)", "Bash(npm test *)" ], "deny": [ "Read(./.env)", "Read(./.env.*)" ] } } A Stop hook, configured the same way in settings.json , is a further option worth knowing about. It runs a chosen shell command each time the assistant finishes responding, which can be pointed at the credential check script so it runs automatically after any milestone that touches .env , rather than depending on the assistant remembering the instruction in the plan. The Claude Code hooks documentation is linked below. Other LLM code assistants have similar features. Handing off the finished plan Once the plan reads correctly end to end, implementation itself is one request. Work through plan.md from top to bottom. After finishing each item on the milestone checklist, check it off in the file, confirm the change renders correctly in the browser, and report the result before starting the next item. Re-read plan.md at the start of each milestone rather than relying on memory of earlier parts of this conversation. Stop and ask only when a decision is not covered by the plan. The instruction to re-read the file matters on a long session. It is what keeps the assistant's sense of what is done and what remains accurate even after earlier parts of the conversation have been condensed. Resuming and checking status Because the plan and its checklist live on disk, a new session, or the same session after a break, can pick up where the last one left off. Read plan.md and tell me which milestones are checked off, what remains, and whether any of the finished ones still need a browser check before I can consider them done. This works whether the pause was intentional or the result of the assistant stopping to ask about something the plan did not cover. Example planning document The following is a shortened example of what a finished plan looks like before implementation begins, for a small internal ComposeSDK app. # Regional Sales Pulse *Sisense ComposeSDK Planning Document* ## Purpose Built as a React ComposeSDK application for the regional sales managers who currently pull this picture together from three spreadsheets before the weekly pipeline review. The app should answer, at a glance, whether a region or category is trending up or down. It exists specifically for that meeting, and is meant to make it faster and more informative. ## Data model and what it contains Sample ECommerce (src/models/sample-ecommerce.ts). Revenue and Units are the two figures managers actually watch weekly. Category and Country are the two dimensions they currently cross-reference by hand for trends. Condition (New/Used) does not matter here and should not appear on any page unless someone asks for it later. ## Pages, filters, and interactivity 1. Overview. Revenue and Units by month, column chart. This is the page a manager opens first, so it should load with the current calendar year already selected. 2. Regional Breakdown. Revenue by Country, map visualization. 3. Product Performance. Revenue by Category, ranked bar chart, highest to lowest. Two filters sit at the top of the app and apply across all three pages, a date range defaulting to the last two weeks, and a country selector. Both should be visible without opening a menu. ## Visual style Matches the internal tools intranet look, navy header, white background, no dark mode needed for this audience. Cards with some padding around each chart rather than charts running edge to edge. Nothing more elaborate than that is expected here. ## Connection and verification URL and token in .env, read access denied per project settings. Re-run scripts/check-credentials.mjs only if these values change. After each milestone, confirm the change actually renders correctly in the browser. ## Milestones - [x] Scaffold three page routes with placeholder headers and the shared filters wired to nothing yet - [ ] Overview page with Revenue and Units by month - [ ] Regional Breakdown page with Revenue by Country as a map - [ ] Product Performance page with Category ranked by Revenue - [ ] Shared date range and country filters applied across all three pages - [ ] Navigation between the three pages - [ ] Visual pass matching the style notes above ## Testing Add unit and integration tests where they make sense, and skip them where they don't. Use headless browser screenshots for visual checks, the same way each milestone gets confirmed in the browser. Confirm at least once, early on, that a real query actually returns data, since the credential check script only proves the token authenticates, not that a query returns rows. ## Out of scope No user accounts or role management beyond what Sisense already provides. No PDF export or scheduled email in this version. Condition does not appear anywhere unless a later request asks for it. ## Open questions - Should the country filter support selecting more than one country at once? Left single select for now, since that already matches what the spreadsheets show today. Prompt library Drafting and revising. Draft a planning document for [project description] as a [React/Angular/Vue] ComposeSDK application, saved as plan.md. Cover the purpose, why the data matters, which ComposeSDK flavor it uses, each page and its filters, any interactivity, a rough visual style, and a milestone checklist, with open questions listed separately. Use ExecuteQuery to check the actual values in [columns] before finalizing that page in the plan, not just the field names in the schema file. In plan.md, change [specific details] and update the milestone checklist to match. Review plan.md and flag anything ambiguous enough that you would have to guess during implementation. Connection and verification. Add scripts/check-credentials.mjs as described in plan.md, and note that it only needs to run again if the .env values change. After this milestone, confirm it renders correctly in the browser before checking it off. Settings for a longer run. Add an allow rule to .claude/settings.json (or equivalent for the LLM Code Assistant you or using) for [command], so it stops prompting for that one going forward. Add a Stop hook in settings.json that runs scripts/check-credentials.mjs automatically whenever .env changes. Handoff and resumption. Work through plan.md from top to bottom, checking off each milestone as it's finished, confirming each one in the browser, and re-reading plan.md at the start of the next. Stop only for decisions the plan does not cover. Read plan.md and report which milestones are done, what remains, and which finished ones still need a browser check. Useful links From Zero to ComposeSDK ComposeSDK documentation ComposeSDK ExecuteQuery reference Claude Code permissions documentation Claude Code hooks documentation ComposeSDK Github Monorepo Sisense CSDK Github Skills Examples Sisense MCP Github Server Sisense REST API and authentication documentation A written planning document is worthwhile when a application design and purpose is already decided in enough detail to write down once. A application still being thought out piece by piece is usually still faster to build the direct way, one prompt, one page, one widget at a time.

Overview This article explains how to connect Google Analytics to Sisense using the CData JDBC Driver for Google Analytics. You can authenticate in one of two ways: CData embedded OAuth application — simpler setup and recommended when you do not require your own Google OAuth application. Custom Google OAuth application — requires additional configuration but gives you control over the OAuth client credentials. Both methods use the same general workflow: configure and authenticate the CData driver on a machine with browser access, then deploy the driver and OAuth settings to the Sisense server. What you'll learn By the end of this article, you will know how to: Download and install the CData JDBC Driver for Google Analytics. Configure Google Analytics authentication. Generate and persist OAuth credentials. Deploy the CData driver to a Sisense server. Create a Google Analytics connection in Sisense. Prerequisites Before you begin, you should have: Basic familiarity with the Sisense UI. Basic knowledge of Sisense data connectors. Access to the Sisense server or its file-management interface. Basic familiarity with Windows or Linux file systems. A Google account with access to the required Google Analytics property. Authentication options Option 1: CData embedded OAuth application Use this option when you want the simplest setup. CData provides OAuth credentials with the driver, so you do not need to create your own OAuth application in Google. Option 2: Custom Google OAuth application Use this option when you need your own Google OAuth client credentials. This method requires: A Google OAuth application. An OAuth Client ID. An OAuth Client Secret. An authorized redirect URI. The remaining deployment process is largely the same for both methods. Step 1: Download and install the CData driver Download the CData JDBC Driver for Google Analytics and install it on a machine where you can authenticate through a web browser. After installation, locate the driver's lib directory. macOS /Applications/CData/CData JDBC Driver for Google Analytics <version>/lib Windows C:\Program Files\CData\CData JDBC Driver for Google Analytics <version>\lib Locate and open: cdata.jdbc.googleanalytics.jar This opens the CData Connection String Builder. Step 2: Configure authentication Option 1: Use CData embedded OAuth Configure the following properties: AuthScheme=OAuth InitiateOAuth=GETANDREFRESH The initial connection string should look similar to: jdbc:googleanalytics:AuthScheme=OAuth;InitiateOAuth=GETANDREFRESH; Proceed to Step 3: Authenticate with Google . Option 2: Use a custom Google OAuth application Configure: AuthScheme=OAuth InitiateOAuth=GETANDREFRESH OAuthClientId=<client-id> OAuthClientSecret=<client-secret> The connection string should look similar to: jdbc:googleanalytics:AuthScheme=OAuth;InitiateOAuth=GETANDREFRESH;OAuthClientId=<client-id>;OAuthClientSecret=<client-secret>; Configure the redirect URI NOTE: If you don't know how to create custom Google OAuth application - check Creating a Google Application section in this article . In your Google OAuth application, add the following Authorized Redirect URI: http://localhost:33333 Note: If you are migrating from an older Sisense native Google Analytics connector, verify whether its existing OAuth credentials can still be reused before copying values from the old connector configuration. Step 3: Authenticate with Google In the CData Connection String Builder: Select Test Connection . Your default browser opens the Google authentication page. Sign in with the Google account that has access to the required Google Analytics property. Grant the requested permissions. Return to the CData Connection String Builder. After successful authentication, CData updates the connection information with the OAuth credentials. Select Copy to Clipboard to save the resulting connection string. Important: Treat the resulting connection string and OAuth settings as credentials. Do not publish real access tokens, refresh tokens, client secrets, or OAuth settings in screenshots or documentation. Step 4: Locate the OAuth settings file CData persists the OAuth authentication information in OAuthSettings.txt . Typical locations include: Windows %APPDATA%\CData\GoogleAnalytics Data Provider\OAuthSettings.txt macOS ~/Library/Application Support/ If you cannot locate the file, explicitly configure OAuthSettingsLocation in the CData Connection String Builder and repeat the authentication process. Step 5: Copy the OAuth settings to the Sisense server Copy OAuthSettings.txt to a persistent location accessible by Sisense. For example: Windows C:\OAuthSettings.txt Linux /opt/sisense/storage/data/OAuthSettings.txt Make sure the Sisense service can read and write the file. CData must be able to update the OAuth settings when refreshing authentication tokens. Step 6: Deploy the CData JDBC driver to Sisense Copy: cdata.jdbc.googleanalytics.jar to the appropriate JDBC driver directory on the Sisense server. The exact path depends on your Sisense deployment and version. Important: Verify the current Sisense documentation for the supported JDBC driver location before deploying the JAR. Deployment paths have changed between Sisense versions. Step 7: Create the connection in Sisense In Sisense, create a new Generic JDBC connection. Configure the following fields. Connection string Use the connection string generated by CData and specify the location of the OAuth settings file on the Sisense server. For example: jdbc:googleanalytics:AuthScheme=OAuth;InitiateOAuth=GETANDREFRESH;OAuthSettingsLocation="/opt/sisense/storage/data/OAuthSettings.txt"; When using your own Google OAuth application, the connection also includes: OAuthClientId=<client-id>; OAuthClientSecret=<client-secret>; JDBC JARs folder Specify the directory containing: cdata.jdbc.googleanalytics.jar Driver class Use: cdata.jdbc.googleanalytics.GoogleAnalyticsDriver Test the connection and continue to table selection once the test succeeds. Google Analytics 4 If you are connecting to Google Analytics 4, verify the current CData connection properties for GA4. Depending on the CData driver version, you may need properties such as: Schema=GoogleAnalytics4 PropertyId=<property-id> Use the current CData documentation as the source of truth for the properties supported by your installed driver version. Data model considerations The CData Google Analytics schema is not identical to the schema exposed by the former Sisense native Google Analytics connector. Tables, columns, and relationships may therefore differ. If you are migrating an existing Sisense data model, review: Table names. Column names and data types. Existing joins. Custom SQL. Calculated fields. Dashboard dependencies. You may need to modify the data model before rebuilding existing dashboards against the CData source. Troubleshooting Authentication opens successfully but Sisense cannot refresh the token Verify that: OAuthSettingsLocation points to the correct file. The OAuth settings file exists on the Sisense server. Sisense has read and write access to the file. The OAuth credentials correspond to the same Google application used during authentication. The driver works locally but not on the Sisense server Verify that: The CData JAR was copied to the correct Sisense JDBC driver directory. The configured JDBC JAR folder matches that directory. The driver class is: cdata.jdbc.googleanalytics.GoogleAnalyticsDriver Expected Google Analytics fields are missing The CData schema differs from the former native Sisense connector. Review the CData Google Analytics schema documentation and adjust the data model accordingly. Conclusion The CData JDBC Driver provides a way to connect Google Analytics to Sisense through the Generic JDBC interface. For the simplest configuration, use CData's embedded OAuth application. Use a custom Google OAuth application when you need direct control over the OAuth client credentials. Before deploying the connector in production, verify the connection properties, GA4 configuration, and JDBC deployment paths against the documentation for your current CData and Sisense versions.

With the 2026.3 release, Sisense continues to advance AI-powered analytics across the full builder workflow. This release introduces MCP Server (beta), bringing governed data access to external AI agents. This release also brings new tools to help your users find insights faster, model data conversationally, and extend analytics experiences with custom visualizations. Connect AI agents to your data with MCP Server (beta) Your users are already working in AI tools like Claude, ChatGPT, and Cursor. With the Sisense MCP Server, now in beta, they can get governed answers from your data without ever leaving those tools. Any MCP-compatible AI agent can explore your data and build charts through Sisense, scoped to each user’s existing permissions and grounded in your semantic model.  No install, no shared credentials The MCP Server is a fully hosted endpoint secured with OAuth 2.1. There is nothing to install, no shared API key, and no service account to manage. Each connection uses a short-lived, per-user credential that expires automatically. Governed by design Every agent request runs under the signed-in user’s existing permissions, so people only see what they are already allowed to see. And because agents work against your semantic model rather than raw tables, answers reflect your metrics and definitions, not ad hoc interpretations that drift from what your business actually means.  What agents can do Once connected, an agent can: Find the right data without digging through the platform. Ask questions in natural language and get answers in plain language, grounded in your actual metrics. Turn an answer into a chart within that conversation, without switching tools. Build on previous answers to go deeper, using results from earlier in a session, without starting over.  In clients that support interactive content, such as Claude, charts render live inside the conversation. Note: MCP Server is available in 2026.3.1 and later for managed cloud and self-hosted deployments. The AI-powered query and chart tools require Cloud-Linked Features enabled on your instance.  Find the right insight instantly with Sisense Intelligence search With Sisense Intelligence search, users can type what they’re looking for in plain language and instantly surface validated widgets that already live in their dashboards. Intent-driven, permission-scoped discovery Rather than navigating dashboard structures or guessing where an analysis lives, users describe what they need and Sisense Intelligence search surfaces the right widget, ranked by relevance, scoped to what they’re already allowed to see. This works for two distinct user groups: Viewers find answers without needing to understand the data structure or know which dashboard to open. Designers check whether an analysis already exists before building a new one, reducing duplication and keeping dashboards clean. Every result comes from analyses that are already trusted and dashboard-resident. Relevance ranking filters out weak matches, so the top result is ready to act on. Governed by existing permissions Search results are scoped to each user’s existing access rights automatically. No new permissions surface to configure or manage. What a user is entitled to see governs what they find. Extend your product with Compose SDK Plugins (beta) Compose SDK Plugins is now in beta, giving developers a new way to extend Sisense with custom visualizations that feel native to their own applications. Build custom visualizations that fit your product Plugin authors can now define custom React-based widgets and register them directly in Compose SDK and Fusion. Once registered, those widgets appear throughout the Fusion UI, in the widget picker, the New Widget popup, and the widget editor, alongside native Sisense widget types. Want to use third-party libraries to visualize your data? Add the dependencies to your plugin. Or, if you know the behavior, use case, and look and feel you want, but aren’t sure which library to use, the built-in /design-custom-widget skill can help you choose. customWidget: {    name: 'plotly-heatmap',    displayName: 'plotly-heatmap',    visualization: {      Component: HeatmapChart,    },    designPanel: {      Component: HeatmapDesignPanels,    },    dataPanel: {      config: {        inputs: [          {             name: 'categories',            displayName: 'Categories',            type: 'dimension',             maxItems: 1           },          {             name: 'value',             displayName: 'Value',             type: 'measure',             maxItems: 1           },          {             name: 'breakBy',             displayName: 'Break By',             type: 'dimension',             maxItems: 1           }        ],      },    }, Design and embed without leaving your workflow Each new plugin begins its journey right where developers work: in IDEs like VS Code and Cursor, or AI coding agents such as Claude Code. A single command creates the plugin development project, while built-in AI skills provide a simple Q&A workflow that guides you through the design, configuration, build, and deployment of your plugin to the connected Sisense instance, all without writing a single line of code.  Run the included development server locally to preview, test, and iterate on your plugin. Don’t forget to add your new plugin as a Git repo. When you’re ready to see it in Fusion, run the deploy command again or let your agent handle the deployment.  One plugin source, written in React, works seamlessly everywhere: Fusion, Fusion Compose SDK Mode,  Compose SDK (including React, Angular, and Vue frameworks). Cross-filtering that works across the stack Plugins now support automatic cross-filtering in both Fusion and Compose SDK environments, so custom widgets participate in the same filter interactions as native ones, and the experience stays consistent across your analytics. Build data models faster, from upload to final product This release gives teams more ways to build and iterate on data models, whether you are starting from raw data in the assistant or making on-the-fly adjustments directly in the widget editor.  Start from scratch in the assistant Data Modeling Agent is now generally available, giving users a way to go from raw data to a working, queryable model entirely from within the assistant. Upload CSVs, define relationships, and build the ElastiCube by chatting through the process. No tab switching, no separate modeling screen, no manual modeling expertise required. Ready to use across the platform The resulting model feeds directly into your dashboards, embedded analytics, and APIs with no additional handoff step. Once the model is ready, it is ready to use across the platform. You stay in control The agent proposes each next step rather than applying changes automatically. Nothing updates without your approval, so you can move quickly without losing visibility into what is being built and why. Built for fast onboarding, useful beyond it The agent is designed first for teams starting with raw data, where the path from “I have a CSV” to “I have something I can query” is longest. It also supports a secondary flow for refining and improving existing data sources as needs evolve.  Create calculated dimensions directly in the widget (GA) Business analysts and dashboard designers can now create new data grouping and categorization dimensions on the fly (e.g., Concat, Left, Right) directly within the widget editor , without requiring backend data modeling changes or ElastiCube rebuilds. Use the widget editor for: Binning and grouping: Drag-and-drop values into custom groups (e.g., grouping “sku_124” and “sku_124_old” into “sku_124”). String manipulations: Functions to extract parts of text or reshape dates (e.g., LEFT(Region, 3)) to create new axis categories. This makes it faster to iterate on dashboards and adapt to new analytical needs as they arise. Troubleshoot as any user, with a full audit trail Admins can now impersonate lower-tier users directly from the Admin panel, making it possible to reproduce reported issues and verify per-user configurations exactly as that user sees them, without workarounds or support scripts. One click to start, one click to return Impersonation is available as a row action on the Users table in both the Fusion admin grid and the new React admin UI. Once active, a persistent banner identifies the session and confirms that all actions are being audited under the admin’s account. Returning to the admin session is a single click. Built around strict access controls Impersonation follows a strict hierarchy. Only super admins, admins, and tenant admins can initiate a session. An actor can only impersonate a role strictly below their own, and tenant admins are confined to their own tenant. Users at the data admin level and below cannot initiate impersonation under any circumstance. Every session is audited Every action taken during an impersonation session is logged under the initiating admin’s account, not the impersonated user’s. This replaces the ad hoc workarounds that admins and support teams have used previously with a governed, audited, in-product path.  Looking ahead  In the fourth quarter of 2026, our focus will be on deepening the AI experience, expanding analytics capabilities, and giving developers and data teams more flexibility across the platform. We plan to:  Extend BYO LLM support to AWS Bedrock, coming before Q4. Bring the assistant into a side panel experience so it lives alongside your dashboards rather than replacing them. Add new visualization types and query capabilities to give builders and viewers more ways to explore and present data.  Extend the narrative functionality to dashboards. Add composable embedding options to Sisense Intelligence search, and support in assistant. Add custom AI context to improve how assistant understands of your data and business definitions. Introduce governance controls over who has access to AI features across your tenant. Surface detailed usage analytics on the questions users ask and how AI credits are consumed. Extend assistant support to GCP-hosted models. Make it easier for self-hosted customers to enable advanced privacy options by hosting a vector database as part of Sisense. Stay tuned for more details on these features. We want to hear from you Your feedback is crucial in shaping future releases, so be sure to voice your ideas and suggestions in the Product Feedback Forum . 

This article outlines ways to programmatically format Sisense Bar Chart Widget Value labels via widget scripts , covering methods to prevent label overlap and apply consistent styling across all labels. Custom Styling for Data Labels The script below enables the formatting of Chart Widget Value labels by setting a custom background color, padding, and border-radius. Ensure the default data label UI option is disabled. Other CSS and Highcharts settings can be added as needed.         widget.on('render', function (se, ev) { ev.widget.queryResult.plotOptions.bar.dataLabels = { backgroundColor: '#f5d142', color: 'white', padding: 5, borderRadius: 5, enabled: true } })       Preventing Label Overlap The script below manually adjusts value label positioning to prevent overlap in densely populated bar chart widgets. The exact formulas for label positioning can be changed as needed.         widget.on('domready', function (se, ev) { var barWidth = $('.highcharts-series-group .highcharts-series rect', element).width(); $('.highcharts-data-labels .highcharts-label', element).each(function () { var labelWidth = $(this).find('rect').width(); var labelHeight = $(this).find('rect').height(); $(this).find('rect').attr('x', ($(this).find('rect').attr('x') + 2)); $(this).find('rect').attr('height', barWidth); $(this).find('rect').attr('y', ((labelHeight - barWidth) / 2)); }) })         Dynamically Increase Space for Labels If bar value labels overlap with the chart bars, you can dynamically adjust the maximum value on the y-axis to create additional space. A different formula, or a hard-coded value, can also be used as the y-axis maximum value.         widget.on('processresult', function (se, ev) { var maxValue = 0; var increasePercent = 0.2; ev.result.series.forEach(function (series) { series.data.forEach(function (dataItem) { if (dataItem.y > maxValue) maxValue = dataItem.y; }) ev.result.yAxis[0].max = maxValue + (increasePercent * maxValue); }) })       Conclusion These scripts enable customizing dynamically formatted and well-positioned data labels in your Sisense charts, enhancing readability and aesthetics beyond the default Sisense data bar data labels in bar chart widgets. For further discussion of these types of scripts, see the  Dynamically Formatted Data Labels article   Example Of Custom Labels Added via Scripting Y-Axis Maximum Set To a Very Large Value Check out this related content:  Academy Documentation