TL;DR: Embedding dashboards directly into SaaS applications, customer portals, and business platforms helps users access insights without leaving their workflows. However, providing seamless access while maintaining security can be challenging. JWT authentication helps organizations securely authenticate users, support single sign-on (SSO), and deliver embedded dashboards without requiring separate login experiences, creating a more secure and user-friendly analytics environment.

Introduction

Organizations increasingly embed dashboards into SaaS applications, customer portals, and business platforms to deliver analytics within existing user workflows. As embedded analytics adoption grows, providing secure access without disrupting the user experience becomes a critical requirement. Users expect to sign in once and access all application features, including embedded dashboards, without additional login prompts. At the same time, organizations must ensure that only authorized users can access analytics content.

JWT (JSON Web Token) authentication helps address this challenge by securely passing authenticated user information between applications and embedded dashboard environments. This enables seamless Single Sign-On (SSO), reduces login friction, and supports secure dashboard access across modern embedded analytics deployments.

What Is JWT Authentication?

JWT (JSON Web Token) is an open standard for securely transmitting authenticated user information between systems. In embedded dashboard environments, applications generate signed tokens that allow dashboards to verify user identities without requiring a separate login.

Because the token is digitally signed, the receiving system can validate its authenticity before granting access. This makes JWT authentication a practical approach for enabling secure Single Sign-On (SSO) and seamless dashboard access within SaaS applications, customer portals, and other embedded analytics environments.

How JWT Authentication Simplifies Dashboard Embedding

As organizations embed dashboards into customer portals, SaaS applications, and business platforms, authentication plays a critical role in delivering a secure and seamless user experience. JWT authentication helps simplify dashboard embedding by enabling trusted access between applications and analytics environments.

JWT authentication helps organizations:

• Enable Single Sign-On (SSO): Allow users to access embedded dashboards using their existing application credentials without requiring separate logins.
• Improve User Experience: Create a seamless dashboard experience by reducing authentication friction and minimizing interruptions during user workflows.
• Establish Trusted Authentication: Securely transfer authenticated user information between applications and embedded dashboards using signed JWT tokens.
• Simplify Integration: Connect embedded dashboards with existing authentication systems without requiring users to manage multiple sets of credentials.
• Support Secure Access Management: Validate user authentication before granting access to embedded dashboards and analytics resources.

By simplifying authentication and reducing login friction, JWT authentication helps organizations deliver embedded dashboard experiences that are both secure and user-friendly.

When Should You Use JWT Authentication?

JWT authentication is most valuable when embedded dashboards need to feel like a seamless part of your application rather than a separate analytics platform. By allowing applications to securely pass authenticated user information, JWT helps simplify access while maintaining security.

Organizations commonly use JWT authentication for:

• Customer portals that provide personalized analytics
• SaaS applications with embedded dashboards
• Multi-tenant environments that require user-specific data access
• Partner portals that share analytics with external stakeholders
• Customer-facing dashboards that require secure single sign-on experiences

In these scenarios, JWT authentication helps reduce login friction while ensuring users can securely access the data and dashboards relevant to them.

JWT Authentication vs Traditional Login Workflows

Organizations embedding analytics into customer-facing applications often need to balance security and user experience. While traditional login workflows may require users to authenticate separately for analytics access, JWT authentication enables a more seamless experience by securely transferring authentication information between systems.

For organizations embedding analytics into customer portals, SaaS applications, partner portals, or other customer-facing solutions, JWT authentication helps streamline access while maintaining secure control over user permissions and dashboard visibility.

How Bold BI Supports JWT Authentication for Embedded Dashboards

Bold BI® helps organizations implement JWT authentication for embedded dashboards by providing the capabilities below. JWT-based SSO is available in self-hosted deployments (Managed Private Cloud and On-Premises); Cloud Edition does not support SSO.

• JWT-Based Authentication: Authenticate users through signed JWT tokens and securely deliver embedded dashboards within SaaS applications, customer portals, and multi-tenant environments.
• Single Sign-On (SSO): Allow users to access embedded dashboards using existing application credentials without requiring separate analytics logins.
• Secure Dashboard Access: Validate authenticated user information before granting access to dashboards and analytics content.
• Embedded Analytics Integration: Embed dashboards directly into applications while maintaining a seamless user experience across authentication workflows.
• Support for Multi-Tenant Environments: In Managed Private Cloud and On-Premises deployments, combine JWT authentication with access controls to help ensure users only access the dashboards and data relevant to them.
• Security Controls for Authentication Workflows: Strengthen authentication security through token validation, encryption options, and secure callback workflows.

By combining JWT authentication with embedded analytics, organizations can simplify dashboard access, reduce login friction, and support secure customer-facing analytics deployments.

How JWT Authentication Works in Embedded Dashboards

JWT authentication enables organizations to provide secure Single Sign-On (SSO) access to embedded dashboards without requiring users to maintain separate analytics credentials. In Bold BI, the authentication workflow helps establish a trusted connection between the host application and the embedded dashboard environment. The following workflow illustrates how authenticated user information flows between the host application, JWT authentication layer, Bold BI, and the embedded dashboard environment.

How to Implement JWT Authentication in Bold BI

After understanding how JWT authentication works, organizations can configure JWT authentication in Bold BI to provide secure, seamless access to embedded dashboards. JWT authentication is configured in self-hosted deployments (Managed Private Cloud and On-Premises).

Step 1: Configure JWT Authentication

In the Bold BI Dashboard Designer, navigate to the JWT authentication settings and configure the required provider details, including the remote login URL and logout URL used during authentication. The remote login URL is used to redirect users to the application’s login page when authentication is required, helping establish secure communication between the application and embedded dashboards.

Step 2: Generate and Secure the JWT Credentials

After the JWT configuration is saved, Bold BI generates a signing key that applications use when creating JWT tokens. Organizations can also enable JWT encryption to add an extra layer of protection for authentication data.

Step 3: Authenticate the User

When a user attempts to access an embedded dashboard, authentication occurs through the organization’s existing application. This allows businesses to maintain a familiar login experience while supporting seamless access to analytics resources.

Step 4: Validate the Authentication Request

Once authentication is completed, the application passes the JWT token through the configured callback flow. Bold BI then validates the JWT response before granting access to dashboards and analytics content.

Step 5: Enable Secure Access Across Environments

By default, Bold BI uses secure HTTP methods for JWT authentication. Organizations that require legacy workflows can configure request handling settings, helping ensure authentication aligns with their deployment requirements.

Step 6: Access Embedded Dashboards

After the JWT response is validated, users can access embedded dashboards without completing a separate login process. This creates a seamless analytics experience while maintaining secure authentication across systems.

By combining JWT-based Single Sign-On with embedded dashboards, organizations can simplify user access, reduce login friction, and deliver a more integrated analytics experience within their applications.

Want to implement JWT authentication in your application? Explore the Bold BI JWT Authentication documentation.

Authentication Considerations for JWT-Based Dashboard Embedding

Implementing JWT authentication for embedded dashboards requires careful planning to ensure secure, reliable, and seamless access across applications and analytics environments. While JWT simplifies authentication and supports single sign-on experiences, organizations should follow several best practices during implementation.

• Use Secure Signing Keys: JWT tokens should be signed using a trusted signing key to help verify the authenticity of authentication requests. Protecting signing keys is essential for maintaining a secure authentication workflow.
• Configure Appropriate Token Expiration: Setting reasonable token expiration periods helps reduce security risks while ensuring users can access dashboards without unnecessary interruptions.
• Consider Token Encryption When Needed: For environments with additional security requirements, JWT encryption can provide an extra layer of protection for authentication data contained within token payloads.
• Validate Authentication Requests: Authentication requests should be validated before granting access to embedded dashboards. Proper validation helps ensure that only authorized users can view analytics content.
• Use Secure Transport Methods: JWT tokens should always be transmitted over HTTPS to help protect sensitive authentication information during transit. When available, secure request methods such as HTTP POST can help reduce exposure risks compared to passing tokens through URLs.
• Manage User Access Carefully: User identities, roles, and permissions should be aligned with organizational access policies to ensure users can only view the dashboards and data relevant to them.

By following these practices, organizations can build a secure and scalable JWT authentication framework that helps protect embedded analytics environments while delivering a seamless user experience.

Conclusion

Embedded dashboards have become a key component of modern SaaS applications, customer portals, and digital business platforms. However, delivering dashboards securely without creating login friction remains a significant challenge.

JWT authentication helps organizations simplify dashboard access by securely sharing authenticated user identity information between systems. This enables seamless single sign-on experiences, improves security, and reduces authentication complexity.

For businesses looking to provide secure and user-friendly embedded dashboard experiences, JWT authentication offers an effective foundation for modern authentication workflows. By combining secure authentication with embedded analytics, organizations can improve user adoption, reduce login friction, and deliver a more connected analytics experience.

Looking to implement secure JWT authentication for embedded dashboards?

Start a free trial or schedule a personalized demo to see how Bold BI® helps organizations deliver secure, seamless access to embedded analytics through JWT-based authentication and Single Sign-On.

Frequently Asked Questions

1. What is JWT authentication?

JWT authentication uses digitally signed tokens to securely transmit authenticated user information between systems.

2. Why is JWT authentication useful for embedded dashboards?

JWT authentication allows users to access embedded dashboards without repeated login prompts while maintaining secure identity verification.

3. Does JWT authentication support single sign-on?

Yes. JWT authentication is commonly used to provide seamless single sign-on experiences across connected applications.

4. Is JWT authentication secure?

When implemented with token validation, HTTPS, secure key management, and expiration controls, JWT authentication provides a secure authentication framework.

5. Can JWT authentication be used in SaaS applications?

Yes. JWT authentication is widely used in SaaS applications to provide secure user authentication and improve user experiences across integrated systems.

6. How does Bold BI support JWT authentication?

Bold BI supports JWT-based authentication, enabling organizations to authenticate users and provide seamless access to embedded dashboards and analytics experiences. JWT-based SSO is available in self-hosted deployments (Managed Private Cloud and On-Premises); Cloud Edition does not support SSO.

Originally published at https://www.boldbi.com on November 2, 2026.

JWT Authentication for Embedded Dashboards | Bold BI was originally published in Bold BI on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR: When embedding dashboards in Bold BI 14.1 and later, enforce row-level access through embed tokens generated by your server. Use data filters when access rules map directly to dataset columns and custom attributes when access depends on tenant, role, or database context. Never accept filter values from the browser. OWASP A01:2025 identifies broken access control as the leading application security risk, making server-side enforcement essential.

Why one wrong filter value matters

One incorrect filter value is all it takes to expose one customer’s data to another customer. In a multi-tenant SaaS application, that kind of access-control failure can quickly become a security incident.

Consider a hypothetical clinic-management SaaS platform used by multiple healthcare providers. Every clinic accesses the same embedded analytics experience, but each clinic should see only its own patients, appointments, and financial data. The challenge is ensuring those restrictions cannot be bypassed.

In Bold BI®, data filters and custom attributes provide two different ways to implement tenant-aware access control.

This article explains when to use each option, where security rules should be enforced, how embed tokens protect customer data, and how to avoid common mistakes that can lead to data exposure across embedded analytics and customer-facing analytics applications.

How the embed token enforces access

Every embed request includes information required to identify the Bold BI environment and user context, such as:

The embed secret never goes into the token. Your server uses it to sign the request before the token is returned to the application. For anonymous embedding, the token includes:

A secure embedded analytics implementation starts on your backend. After a user signs in, your application sends a request to your backend. The backend determines which data the user can access, adds data filters or custom attributes to the embed token, signs the request using the embed secret, and returns the token to the application. When the dashboard loads, the Bold BI server applies those rules before any data is returned to the user.

After generating the embed token, your backend returns it to the application. The front end then passes that token to the Bold BI embedding SDK when calling BoldBI.create(). The dashboard renders using the signed token, and all access-control rules defined in the token are enforced by the Bold BI server rather than the browser.

Data Filters for Field-Based Rules

Data filters are best suited for access rules that map directly to values stored in dataset columns.

Common examples include:

• Region
• Country
• Department
• Product Category

In the clinic SaaS example, a regional manager may need access only to clinics located in specific regions.

app.post('/tokenGeneration', function (request, response) {

  const embedDetails = {

    ...,  // Existing required details

    datasourcefilters: [

      { name: "shipCountry", value: "India", operator: "=" },

      { name: "Region", value: ["North", "East"], operator: "IN" }

    ]

  }

});

The values must come from your server’s own records for the signed-in user, never from the request the browser sends. The row-level security documentation has the same example in .NET and PHP. To configure data filters in Bold BI, define filter rules on dataset fields and pass the permitted values through your server-generated embed token. Visit our documentation to learn how to configure data filters in your dashboard.

Custom Attributes for Tenants and Roles

Custom attributes are name-value pairs that can be defined at the user, group, or site level. Unlike data filters, they provide contextual information that dashboards, queries, and connections can consume dynamically.

app.post('/tokenGeneration', function (request, response) {

  const embedDetails = {

    ...,  // Existing required details

    customattributes: [

      { name: "database_name", value: "DB2", operator: "" },

      { name: "department", value: ["ECE", "IT"], operator: "IN" }

    ]

  }

});

Custom attributes become especially valuable when tenant context drives access decisions rather than values stored in a dataset.

In the clinic example, a clinic_db attribute points each manager’s session to the correct database for that tenant. Because attributes can live at the group level, onboarding stays simple. A new manager joins the clinic’s group and inherits its attributes, so nobody edits token code for each hire. Keep attribute names consistent across tenants (clinic_db, never clinicDB in one place and db_name in another), because a name that doesn’t match fails quietly and is hard to spot in review.

To configure custom attributes in Bold BI, create name-value pairs at the user, group, or site level and reference them within dashboards, queries, or data connections. Explore our help documentation to learn how to configure it in your embedded dashboards.

Data Filters vs. Custom Attributes: How to Choose

Both approaches help enforce secure access in embedded dashboards, but they solve different problems. Understanding where each fits can help you build a simpler, more scalable security model for your application.

Many embedded analytics teams use both: custom attributes to identify the tenant and data filters to narrow the rows within that tenant’s data.

The right approach depends on your isolation requirements, operational complexity, and deployment model. Learn more in the Multitenancy page.

5 Mistakes That Leak Tenant Data

Even with the right security model, configuration mistakes can expose data across tenants. Review these common pitfalls to help keep embedded dashboards secure.

1. Reading filter values from the browser. If the page can send clinic=42, a user can send clinic=43. Look the value up on the server from the authenticated session.
2. Using deny lists as the boundary. NOT IN is fine for trimming results, but security should allow only what a user may see. A new tenant added tomorrow should be invisible by default.
3. Shipping the embed secret to the client. Keep it in server configuration or a secrets manager, never in front-end bundles or public repositories.
4. Skipping required operators after upgrading. In newer versions, operators such as IN must be specified explicitly. Review existing filtering implementations after upgrading.
5. Testing as one user only. A dashboard that looks right for your test account tells you nothing about the tenant next door.

Test It Before You Ship

Following a few security best practices can help ensure data filters and custom attributes consistently enforce tenant isolation. Use the checklist below to validate your implementation before moving to production.

1. Create two test users in different tenants with overlapping data.
2. Generate tokens for each through your real backend, not a test script.
3. Open the same dashboard as both users and compare row counts and totals.
4. Try to tamper: change any client-side value you can find and confirm the output doesn’t change.
5. Repeat after every upgrade that touches embedding.
6. Check cached results aren’t shared.
7. Ask AI Assistant the same question as both users.

OWASP advises including access-control checks in unit and integration tests.

Where to Go Next

For the portal-based approach with user filters, see enabling row-level security with embedded BI. For more multi-tenant patterns, the secure multi-tenant data access webinar notes walk through authenticated and anonymous users, and the multitenancy overview covers tenant setup.

Before presenting your embedded analytics implementation to a customer’s security team, be prepared to demonstrate:

• Where access-control rules are generated and enforced, including data filters and custom attributes applied through embed tokens.
• Where the embed secret is stored and how it is protected from client-side access.
• Results from two-user tenant-isolation testing that confirm users can access only their authorized data.
• Your upgrade validation process, including how access controls are re-tested after embedding-related updates.

Once your token rules hold under testing, you can confidently explain your choice of data filters and custom attributes to customer security and compliance teams.

Bold BI helps organizations implement secure embedded analytics through server-generated embed tokens, row-level security, data filters, and custom attributes. Whether you’re building customer-facing analytics, SaaS dashboards, or multi-tenant reporting environments, Bold BI provides the tools needed to enforce tenant-aware access controls while maintaining a seamless user experience.

Try it on your own data: start a free trial and build the two-tenant test described in this article to validate your access-control model before moving to production.

Frequently Asked Questions

1. Do my customers need Bold BI accounts to view embedded dashboards?

No. Anonymous embedding allows customer-facing dashboards to be viewed without requiring individual Bold BI accounts. It is supported through the single-dashboard viewer experience.

2. Can a user change the filter values in an embed token?

Not if the token is generated and signed on the server. Users should never control filter values directly.

3. Can a single dashboard serve tenants with separate databases?

Yes. Custom Attributes can provide database-specific context that allows a single dashboard template to connect to multiple tenant databases.

4. Which operators do embed token rules support?

Embed-token rules support =, IN, and NOT IN.

5. How do data filters and custom attributes work together?

Many embedded analytics implementations use both. Custom attributes identify the tenant, role, or database context, while data filters restrict the rows a user can view within that context.

Originally published at https://www.boldbi.com on October 6, 2026.

Data Filters vs. Custom Attributes for Embedded Dashboards was originally published in Bold BI on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR: The Bold BI Free Tier is a fully managed evaluation environment that allows organizations to evaluate dashboard creation, data connectivity, embedded analytics, user management, and reporting capabilities without installation or infrastructure management. It helps teams validate analytics requirements and determine whether Bold BI meets their business and technical needs before deployment.

Evaluating a business intelligence platform should help organizations quickly understand its capabilities without time-consuming installation and complex infrastructure setup. Yet many analytics platforms require teams to configure environments and manage technical prerequisites before they can begin exploring features.

The challenge is that organizations often need a practical way to assess embedded analytics capabilities before committing to a deployment strategy. The assessment process should focus on determining business value rather than managing infrastructure.

This is where the Bold BI Free Tier comes in. Bold BI, developed by Syncfusion® , provides a fully managed evaluation environment that enables organizations to assess dashboarding, data connectivity, and embedded analytics capabilities without managing infrastructure. It provides a fully managed environment hosted by Bold BI, allowing organizations to explore analytics capabilities without ongoing infrastructure management. Designed specifically for evaluation, the Free Tier enables organizations to experience the platform and assess how it fits their analytics requirements.

In this blog, you’ll learn what the Bold BI Free Tier is, the features available in the evaluation environment, current limitations, how to get started, and when to consider a full deployment option.

What is the Bold BI Free Tier?

The Bold BI Free Tier is a fully managed evaluation environment that allows organizations to evaluate dashboard creation, data source connectivity, embedded analytics, and user management capabilities without installation or infrastructure management. It is designed for organizations that want to assess Bold BI before selecting a deployment option.

With the Free Tier, organizations can:

• Explore dashboard creation capabilities.
• Connect to 140 supported data sources, cloud platforms, and business applications.
• Build and test analytics workflows.
• Assess embedded analytics use cases.
• Explore platform administration and user experiences.

To better understand the value of the Free Tier, let’s look at the key areas you can explore.

What features are available in the Bold BI Free Tier?

The Free Tier includes essential core capabilities to help organizations evaluate Bold BI:

1. Interactive dashboard creation: Build and customize dashboards using a variety of visualization widgets to analyze and present data effectively.
2. Data source connectivity: Connect to more than 140 supported databases, cloud platforms, and business applications.
3. Embedded analytics: Evaluate how dashboards can be embedded into web applications, customer portals, and internal business systems using Bold BI’s embedded analytics capabilities.
4. Dashboard templates and sample data: Get started quickly with prebuilt templates, sample dashboards, and datasets available in the environment.
5. User management and secure sharing: Test user permissions, role-based access control, and dashboard-sharing capabilities commonly used in production BI deployments.

Beyond these, the Free Tier offers several advantages that simplify the assessment process.

Why organizations use the Bold BI Free Tier for evaluation?

These features of the Free Tier help organizations focus on evaluating analytics capabilities and real-world use cases:

1. Quick setup experience: Start evaluating Bold BI immediately in a fully managed environment where hosting, updates, maintenance, and infrastructure management are handled by Bold BI, allowing teams to focus entirely on validating analytics requirements.
2. Quick access to analytics capabilities: Gain immediate access to dashboards, visualizations, data connectivity, and reporting features, helping teams assess core platform functionality from the first day of evaluation.
3. Designed specifically for evaluation: The Free Tier enables organizations to validate reporting requirements, test embedded analytics scenarios, and assess dashboard functionality before committing to a deployment approach.
4. Easy way to assess embedded analytics functionality: Evaluate how dashboards can be embedded into applications, portals, and websites, helping teams determine whether embedded analytics capabilities align with their product and business requirements.

Which features are not available in the Bold BI Free Tier?

The Free Tier focuses on evaluating dashboarding, analytics, and data connectivity capabilities. The following platform administration and deployment features are not available in the Free Tier:

• Multisite management
• Data process settings
• Authentication settings
• Email settings

Which features are not available in the Bold BI Free Tier?

Some features are available in the Free Tier but have restricted functionality:

• Branding customization options: Advanced branding and appearance customization features are restricted because the user management system (UMS) settings are not available in the Free Tier.
• Site configuration: Some site-level administrative settings cannot be fully configured due to the absence of UMS-related functionality.
• Limited user directives support: User directives work only with Azure AD and database integrations. Windows AD-based directives are not supported in the Free Tier.

To explore the limitations in more detail, refer to the Bold BI Free Tier environment limitations documentation.

Bold BI Free Tier vs Full Deployment

The following table highlights the key differences between the Bold BI Free Tier and a full deployment.

How to get started with the Bold BI Free Tier

Step 1: Sign up or create an account

To access the Bold BI Free Tier, create an account on the Bold BI website or sign in if you already have one.

Step 2: Click the Free Tier URL

After signing in, your Free Tier environment details are shown at the top of the My Dashboard page. Click the link under URL, to the right of Tenant Name, to launch your Bold BI Free Tier instance.

Step 3: Explore the Free Tier

Start exploring sample dashboards, create new dashboards, and connect data sources to evaluate Bold BI.

After accessing the Free Tier, following a structured evaluation approach can help maximize its value.

How Bold BI supports product evaluation

The Bold BI Free Tier is designed to help organizations evaluate key analytics capabilities in a controlled environment. Teams can create dashboards, connect business data sources, test embedded analytics workflows, configure user permissions, and assess reporting capabilities in a managed evaluation environment.

How to evaluate the Bold BI Free Tier effectively

1. Use representative business data: Connect data that closely reflects your real-world reporting needs so you can accurately assess dashboard design, data modeling, and visualization capabilities.
2. Test real analytics requirements: Create dashboards and reports that mirror actual business scenarios, such as sales tracking, marketing performance, or operational monitoring, to determine how well the platform meets your needs.
3. Evaluate different use cases: Explore a variety of analytics scenarios, including executive dashboards, self-service reporting, and departmental reporting, to understand the platform’s flexibility.
4. Explore embedded analytics capabilities: If you plan to integrate analytics into an application or portal, test dashboard embedding, customization options, and user interactions to evaluate the embedded experience.
5. Assess user experience and performance: Review dashboard responsiveness, navigation, visualizations, and overall usability to ensure the platform delivers a smooth experience for end users.
6. Consider administrative limitations: Keep in mind that the Free Tier is intended for evaluation and does not include all platform administration features available in self-hosted or fully managed deployments.

Following these practices will help you decide whether Bold BI aligns with your analytics, embedding, and deployment requirements. One final consideration is whether the Free Tier is appropriate for production environments.

When should you use the Free Tier?

The following table outlines common scenarios and whether the Bold BI Free Tier is the recommended option.

Is the Free Tier suitable for production use?

The Free Tier is designed exclusively for evaluation and proof-of-concept activities. Organizations requiring advanced administration capabilities, deployment customization, authentication management, multisite support, or production-grade environments should use a full Bold BI deployment instead.

If you need access to the complete set of Bold BI features, a self-hosted deployment is recommended. A self-hosted environment provides access to the full range of functionalities available in Bold BI.

If you require a cloud-based trial environment without the Free Tier limitations, the Bold BI presales team can provide a free managed installation for evaluation purposes upon request through a support ticket. For more information about self-hosting, see the Bold BI deployment.

Conclusion

The Bold BI® Free Tier provides a practical way for organizations to evaluate dashboard creation, data connectivity, embedded analytics, reporting, and user management capabilities without installation or infrastructure management. While certain administration features are unavailable, the environment offers a structured way to assess whether Bold BI aligns with business, technical, and deployment requirements before moving to a full implementation.

Whether you’re evaluating customer-facing analytics or embedded BI scenarios, the Free Tier helps you explore Bold BI’s core capabilities and assess its fit for your business needs.

As you evaluate the platform, you can follow the built-in quick tour to get started quickly, request a personalized demo to see Bold BI in action and discuss deployment options with the team, and access the support portal whenever you need assistance.

Frequently Asked Questions

1.What is the Bold BI Free Tier?
The Bold BI Free Tier is a fully managed evaluation environment that allows organizations to explore dashboarding and analytics capabilities without installing or maintaining infrastructure.

2. Who can use the Free Tier?
The Free Tier is available to organizations that want to explore Bold BI capabilities before selecting a deployment option.

3. What can I evaluate in the Free Tier?
You can explore the platform’s core dashboarding, analytics, and data integration capabilities.

4. Is the Free Tier intended for production use?
No. The Free Tier is designed solely for evaluation and testing purposes.

5. What features are not available in the Bold BI Free Tier?
Some platform administration and deployment-related features are not available in the Free Tier, including multisite management, data process settings, authentication settings, and email settings.

6. What features are partially supported in the Bold BI Free Tier?
Certain features are available with limitations, including look-and-feel settings, site settings, and user directives. Some functionality is restricted because user management system settings are not available in the Free Tier environment.

7. How can I access all Bold BI features?
Organizations that require the complete feature set, advanced administration capabilities, or production-ready deployments can explore self-hosted deployment options. If you require a cloud-based evaluation without Free Tier limitations, the Bold BI presales team can provide a managed trial environment upon request.[GH1]

8. Where can I learn more about Free Tier limitations?
Additional details about current environment limitations are available in the Bold BI knowledge base.

Originally published at https://www.boldbi.com on October 13, 2026.

What Is the Bold BI Free Tier? Features and How to Get Started was originally published in Bold BI on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR: One of the most common dashboard embedding security mistakes happens before the dashboard even loads: exposing the embed secret in browser code. A more secure approach is to keep the embed secret on your server, generate an embed token through your back end, and pass only that token to the JavaScript application.

Bold BI® is a dashboard, AI, self-service, and embedded analytics platform from Syncfusion® that helps you turn your data into clear answers. It allows you to embed interactive dashboards directly in your product, so your customers see their numbers without leaving your application.

This guide explains secure dashboard embedding in a JavaScript application, keeping the embed secret on your server, sending only a token to the browser, and applying row-level security (RLS) so each customer sees only its own data.

Why secure dashboard embedding matters to your business

Your customers expect to see their numbers inside your product, not in a separate tool. Embedded dashboards can shorten the time it takes to find an answer, reduce the number of tools people switch between, and give your product team a clear way to show value. Every one of those benefits depends on a single rule. Each customer must see only their own data.

If you are comparing analytics platforms, the questions are practical. Can each customer see only its own data? Can the platform run in our environment? Can our team launch without a long build? Secure embedding answers each of those questions, and this guide shows you where to check.

Every Bold BI edition includes a 30-day free trial with no credit card required, allowing teams to evaluate embedding, security, multitenancy (in Managed Private Cloud and On-Premises), and deployment capabilities before making a decision. You can also explore available editions, deployment options, and licensing details on the Bold BI pricing page to determine which plan best fits your organization’s requirements.

How secure dashboard embedding works in Bold BI

In a production setup, your server stores the embed secret and the browser receives only a time-limited authorization token. That token is tied to a Bold BI user, so the dashboards and data a viewer can reach follow that user’s permissions.

Here’s how a typical production flow works:

• User authentication: A user signs in to your application.
• Token generation: Your back end requests an authorization token from Bold BI using the embed secret it stores.
• Token delivery: The back end returns only the token to the browser.
• Dashboard loading: Your JavaScript app uses the token to list and display dashboards.

Because the embed secret never leaves your server, it can’t be exposed through client-side code.

Tip: The JavaScript dashboard embedding sample is designed for quick local testing, so it generates the token in the browser. For production, move token generation to your back end so the embed secret stays on your server.

With the flow in place, the next step is to confirm you have the required components before embedding a dashboard. Once they’re ready, your application can display a fully interactive Bold BI dashboard inside its own interface, like the one shown in the following image.

To learn more about how dashboard embedding works in Bold BI, visit our help documentation.

What you need before embedding a Bold BI dashboard

Before you write any code, make sure you have:

• A Bold BI environment, either Bold BI Cloud or your own server (Enterprise).
• A published dashboard and its dashboard ID.
• Embed authentication turned on in the Embed settings page of Bold BI.
• A back-end service that can request tokens and store your secret safely.
• A web page or JavaScript application to host the dashboard.
• A Bold BI user account with permission to view the dashboard.

The embed settings page provides the values your server needs, including the server URL, the embed secret, and the environment setting. Keep those values out of front-end code and out of your source repository.

Now that the setup is ready, you can decide how to test it.

Step-by-step guide on embedding dashboards in JavaScript using Bold BI

Before you start, make sure you have the Bold BI environment, embed settings, and back-end service described above. You also need Node.js and Visual Studio Code. Download the JavaScript sample from the official Bold BI GitHub repository. The steps below run that sample on your computer so you can confirm that your dashboard loads with your own data before you build your own integration.

Step 1: Turn on embed authentication and download your settings

In Bold BI, go to Settings > Embed and enable embed authentication. Select Download to download the embedConfig.json file from the same page and place it in the root folder of the sample project.

Step 2: Set the configuration values

Open the embedConfig.json file and enter the following values.

Step 3: Install and start the local server

Open a command prompt in the project folder and run the following commands. The sample supports Node.js versions 14.16 to 18.18.

npm install -g http-server http-server -p 5555

Replace 5555 with any port you prefer.

Step 4: Open the Bold BI dashboard listing

In a browser, open the dashboard listing page. The page fetches your dashboards and lists them. Select Create to open the dashboard designer or select a dashboard and choose Edit to open it in the designer.

Step 5: Open a Bold BI dashboard and check the result

Select a dashboard from the list. The sample builds an embed URL from its ID, name, and category, then displays it inside the page. The finished dashboard should load with its data, as shown.

The sample keeps the embed secret in a local configuration file and creates the token in browser code, so it is for local testing only. For a live application, move the token request to your server as described earlier. Store the secret in a secrets manager such as Bold BI’s README recommends.

Choose between the iframe sample and the SDK

Bold BI supports both iframe-based embedding and the JavaScript Embed SDK. The right choice depends on how much control your product needs.

The iframe sample shows how to list dashboards, view them, and open the designer from your application. It is a practical starting point for a proof of concept, and it runs on Node.js versions 14.16 to 18.18.

The Embed SDK suits production applications that need token-based access, event handling, and deeper control over how the dashboard looks and behaves inside your product.

With the Embed SDK, Bold BI renders the dashboard inside a container element in your page’s DOM. Direct DOM access and changes to internal Bold BI widgets are not supported. To control the dashboard, use the SDK’s official APIs and events, such as loading dashboards or widgets, applying filters, and listening for render and export events. For deeper customization, build custom widgets within Bold BI’s supported framework.

Many teams start with the sample to test their data, then move to the SDK when the product is ready for customers.

When secure dashboard embedding is not the right fit

Secure embedding may not be the right choice in the following situations:

• No back-end service available: Secure embedding requires a back-end service to store the embed secret and generate embed tokens. Without a server-side component, you cannot implement the recommended security model.
• Planning to use the sample in production: The JavaScript sample stores the embed secret in a local configuration file and generates tokens in browser code. It is intended for testing and validation, not production deployments.
• Required RLS capabilities are not supported in your version: If your application depends on row-level security rules that are unavailable in your current Bold BI version, you may need to upgrade or use a different implementation approach.

If any of these scenarios apply, review the row-level security documentation and evaluate the available options before proceeding with your implementation.

Control what each customer sees with row-level security

Row-level security limits which rows of data a user can see inside a shared dashboard. With RLS, you publish one dashboard to every customer instead of building a separate copy for each one. Version 13 is the dividing line for Bold BI RLS methods, so confirm your version before you choose one. Bold BI enforces row-level security at up to three layers: isolation code, custom attributes, and user-based filters. Two token-based approaches are covered here:

• Data filters: Your server adds a filter to the token, such as a region or country. This works well for straightforward rules.
• Custom attributes: Your server passes attributes that identify a tenant, team, or group. Attributes can be set at the user, group, or site level, which suits products that serve many customers.

Consider the Alpha Electronics sales dashboard below. Jack, an admin, can see data for every region, so his total revenue is 184.20M. Grace, a general manager, opens the same dashboard, but her access is limited to the East and North regions. She sees only that data, and her total is 73.26M. The dashboard design is identical for both; only the data each person is allowed to see is different.

The same approach works across customers. For example, a software company that sells project management tools to hundreds of client companies can build one dashboard, and its server passes each client’s tenant attribute in the embed token. Each client sees only its own projects, and the company maintains one dashboard instead of hundreds of copies.

Filters must be enclosed in square brackets and curly braces, as shown in the embed documentation. The query-string method described there applies to Bold BI versions below version 13. Newer versions also offer an object-model approach to RLS, so check the RLS documentation for your version before you choose a method.

Common mistakes to avoid when embedding dashboards securely

Before you launch, watch for these Bold BI embedding issues:

• Leaving token lifetimes at a default value: Set token expiration to match your security policy. The sample default is 10,000 seconds.
• Giving users more dashboard permissions than they need: Grant access by role and review it regularly.
• Testing with only one account: Test with at least two customer accounts to confirm each one sees only its own data.
• Assuming the layout works on every screen: Check the container on desktop, tablet, and phone sizes.
• Customizing the dashboard through the page instead of the SDK: Use the SDK’s APIs, events, and custom widgets, since direct DOM changes are not supported.

Embed Secure Dashboards in Your App

Keep secrets on your server and show each customer only their own data.

Start your evaluation with Bold BI

Secure dashboard embedding allows organizations to deliver analytics directly inside their applications while maintaining strong access controls. By keeping embed secrets on the server, using token-based authentication, and applying row-level security, teams can provide customer-specific analytics experiences at scale with Bold BI.

Secure embedding is easiest to judge with your own customer model. Start a free 30-day trial, or request a demo to walk through your RLS requirements with our team. To go deeper, read the JavaScript embedding sample and the embed viewer documentation. To see the rest of the platform, explore Bold BI embedded analytics, dashboard examples, and the security overview.

Frequently asked questions

1. Do I need a back end to embed a Bold BI dashboard securely?
   Yes. Your server stores the embed secret and requests the tokens that the browser uses.
2. Can each customer see different data in the same dashboard?
   Yes. RLS applied through token filters or custom attributes limits each user to their own rows.
3. Which deployment types are supported?
   Bold BI is available in three editions: Cloud, Managed Private Cloud, and On-Premises, where you run Bold BI on your own server. Set the environment value to match your deployment.
4. Is the iframe sample enough for production?
   It is a practical starting point. For production features such as event handling and deeper control, plan to use the Embed SDK.
5. How do I start evaluating?
   Start with the free 30-day trial, which requires no credit card, or request a demo.
6. Can I implement row-level security for embedded users?
   Yes. Row-level security can be applied during token generation using datasource filters or custom attributes, enabling user-specific access within a shared dashboard.

Originally published at https://www.boldbi.com on November 2, 2026.

How to Securely Embed Dashboards in JavaScript with Bold BI was originally published in Bold BI on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR: When evaluating a Qlik Sense alternative, many organizations compare Bold BI® with other Qlik Sense competitors for embedded analytics, multi-tenancy, deployment flexibility, and pricing. Bold BI and Qlik Sense are both enterprise analytics platforms, but they scale differently depending on how analytics is delivered. For customer-facing, multi-tenant analytics that must run across Cloud, Managed Private Cloud, and On-Premises environments, Bold BI provides more predictable scalability through built-in multi-tenancy, white-labeling, deployment flexibility, flat application-based pricing, and AI-powered analytics.

Although both platforms support analytics and data visualization, they were designed with different priorities in mind. SaaS providers, ISVs, and product teams often need embedded analytics that can scale across customers while maintaining branding, tenant isolation, and deployment flexibility. Internal BI teams may prioritize exploratory analysis, governed analytics, and self-service data discovery. Use the following quick-reference guide to identify which platform aligns best with your requirements.

Bold BI is Syncfusion’s analytics platform for AI-powered, embedded, and self-service analytics. This comparison evaluates Bold BI and Qlik Sense across key areas such as embedding, multi-tenancy, deployment flexibility, AI capabilities, security, pricing, and scalability. For a feature-by-feature breakdown, see the Bold BI Qlik Sense alternative page.

Bold BI vs. Qlik Sense at a glance

The tables below compare Bold BI and Qlik Sense across the criteria that matter most when evaluating embedded analytics platforms, including pricing, deployment flexibility, embedding options, multi-tenancy, AI capabilities, white-labeling, and data connectivity.

Pricing, packaging and deployment

Embedding, multi-tenancy, AI and data

Who is each platform built for?

Bold BI is built for software teams that embed analytics in their own product and for organizations that need self-service dashboards on infrastructure they control. Its 8 core capabilities include a white-label SDK, multi-tenancy, row-level security, and flexible deployment.

Qlik Sense is built for enterprise analysts who explore data across many sources. Its associative engine keeps every value in view after each selection, which suits open-ended discovery. Qlik pairs it with Qlik Talend Cloud for data integration, making it a fit for organizations buying a broad data platform from one vendor.

How does embedding work in Bold BI vs. Qlik Sense?

Bold BI offers 2 embedding methods: an iframe that needs only an embed URL, and a JavaScript SDK that renders dashboards inside your application’s own DOM. The SDK adds event handling, dynamic filters, and full API control over layout. It ships as the npm package @boldbi/boldbi-embedded-sdk and as a CDN script, with 24 documented sample apps covering frameworks including React, Angular, Vue, Blazor, ASP.NET, Java, Python, PHP, Node.js and Flutter.

// Embed a Bold BI dashboard with the JavaScript SDK var dashboard = BoldBI.create({ serverUrl: "https://analytics.yourproduct.com/bi/site/site1", dashboardId: "YOUR-DASHBOARD-ID", embedContainerId: "dashboard-container", embedToken: tokenFromYourBackend // generate on the server; never expose the embed secret }); dashboard.loadDashboard();

Qlik Sense recommends qlik-embed web components, authenticated through OAuth, with JWT and anonymous access also supported. Older approaches such as nebula.js, Capability APIs and iframes remain available.

Bold BI can also embed self-service analytics for your own customers. Component API v2.0 has 7 embeddable components: Viewer, Designer, Multi-Tab, Datasource, AI Assistant, Widget, and Pinboard. Embedding the Designer and Datasource components lets your customers build their own dashboards inside your product, under your branding. See the Bold BI Embed SDK samples for working code in each framework.

How quickly can teams build dashboards in Bold BI vs. Qlik Sense?

Bold BI gets a first embedded dashboard live in 4 steps: connect your data, build the dashboard or ask AI Copilot, secure and brand it, then publish it inside your product. Build dashboards in a drag-and-drop designer with 41 modern widgets across nine categories. AI Copilot creates and edits charts from plain-English requests, and Prompt to Dashboard generates a 6-widget starter dashboard from one prompt.

Qlik Sense apps load and model data through a load script, managed in the Data load editor. The script defines which tables and fields to load and how they link, and Qlik builds its associations during the load. Data Manager adds tables without writing code and generates that script, but custom modeling beyond it means learning Qlik’s script syntax ( source). Teams with SQL skills and no Qlik experience should plan for that learning curve.

How do Bold BI and Qlik Sense handle multi-tenancy?

A single Bold BI instance serves multiple isolated tenants, each with its own database, branding, and delegated admin, and all are managed from one place. Bold BI enforces row-level security at query time through JWT claims, at up to 3 layers: isolation code, custom attributes, and user-based filters. Each tenant can also use its own identity provider, such as Azure AD, Okta, or Auth0.

Qlik’s OEM guidance takes a different approach. Qlik’s terms require a separate Qlik Cloud tenant for each customer organization. Platform Operations APIs create tenants, with a limit of 8,500 tenants per region per license. That provides strong isolation but requires automation to provision and maintain tenants as your customer base grows. Learn more on the Bold BI multi-tenancy page.

How does pricing compare between Bold BI and Qlik Sense?

Bold BI pricing is flat and based on the application. It is not charged per user, per viewer, per seat, or metered by usage. Every edition is priced by custom quote in USD, with no setup fee, free migration, and a 30-day money-back guarantee. Quotes depend on deployment model and scale.

Qlik Cloud Analytics is priced by data capacity, billed annually. Starter costs $300/month for 10 users and 10 GB. Standard costs $825 a month for 25 GB with unlimited users. Premium costs $2,750 a month for 50 GB, and Enterprise starts at 250 GB by quote. Self-hosted Qlik pricing is not published.

The practical difference: Qlik costs rise with the data you load, while Bold BI costs are set by deployment and scale. For a fair comparison, request first-year quotes from both vendors for your expected data volume, tenant count, and end users. See Bold BI pricing.

Example cost scenario

Licensing models are only one part of the evaluation process. As analytics adoption grows, organizations often assess licensing structure alongside scalability, deployment requirements, tenant management, governance, and operational considerations.

Mid-sized SaaS vendor

At this scale, organizations often evaluate platforms based on functionality, deployment preferences, implementation requirements, and expected growth. Both platforms may be suitable depending on analytics needs, customization requirements, and long-term business objectives.

Large SaaS platform

At larger scales, licensing structure, tenant architecture, deployment flexibility, onboarding processes, and operational overhead often become more significant evaluation factors. Organizations typically assess how different licensing and deployment models align with their scalability, governance, administration, and operational requirements.

Key takeaway

These scenarios illustrate that as analytics adoption grows, platform architecture and licensing models often become just as important as features. A solution that meets the needs of a few hundred users may require a different evaluation approach when supporting thousands of customers and tens of thousands of users. Organizations should evaluate analytics platforms based on their specific business, technical, operational, and scalability requirements.

For a more detailed discussion of common embedded analytics pricing approaches and licensing considerations, see Embedded Analytics Pricing: How to Choose the Right Model blog.

What features and support are included in each plan?

Feature availability, usage limits, support levels, and deployment capabilities can directly affect the long-term success of an embedded analytics deployment. The table below compares how Bold BI and Qlik Sense package key capabilities across their respective plans and editions.

Bold BI includes free guided migration assistance and does not charge a setup fee. Organizations evaluating analytics platforms should consider not only features, but also support options, deployment flexibility, scalability requirements, and long-term operational needs when compare plans.

Which deployment options do Bold BI and Qlik Sense support?

Bold BI is sold in 3 editions with identical features. Bold BI fully hosts and maintains the Cloud Edition, including patches, backups, and scaling. Managed Private Cloud runs on dedicated infrastructure in a region you choose. On-Premises Edition runs on Windows, Linux (RHEL, Ubuntu), Docker and Kubernetes, including fully air-gapped environments. You can move from Cloud to self-hosted later without re-platforming.

Qlik Sense is available as Qlik Cloud Analytics (SaaS) or Qlik Sense Enterprise client-managed on Windows servers. Qlik’s own OEM documentation notes that the client-managed version lacks collaboration, automation, alerting, AI, and data integration features found in Qlik Cloud, and follows a fixed release schedule. For regulated teams that must self-host, that gap matters.

How do the AI features of Bold BI and Qlik Sense compare?

Bold BI has 3 AI surfaces sharing one engine. Bold BI also supports the AI Copilot builds and edits charts from plain-English requests in the Dashboard Designer. AI Agent answers questions about the dashboard you are viewing. AI Assistant combines both in a single saved conversation and can be embedded in your app with the SDK. Every license includes 500 AI credits a month, and on-premises users can bring their own OpenAI, Azure OpenAI, or Anthropic key. Model Context Protocol (MCP), enabling compatible AI agents to interact with dashboards and data sources.

Qlik offers AI-powered analytics and Qlik Answers on its Cloud plans, with generative AI from the Standard plan. Qlik Predict, its automated machine learning, is part of the Premium plan. Customer data is not used to train Bold BI’s AI models. See Bold BI AI analytics.

How do Bold BI and Qlik Sense compare on security and compliance?

Bold BI holds SOC 2 Type 2 certification and is independently audited for HIPAA compliance, with a Business Associate Agreement (BAA) available upon request. It also publishes a VPAT (Section 508) and holds TX-RAMP Level 2 certification. Data is encrypted in transit using SSL encryption and at rest using AES-256 encryption. All three editions support SSO through OAuth 2.0, SAML, OpenID Connect, and Azure AD.

Qlik also provides enterprise governance, including role-based access and data lineage connectors on its Premium plan. Check Qlik’s trust center for its current certifications before procurement. Details are on the Bold BI security page.

Where is Qlik Sense stronger than Bold BI?

Qlik Sense is the stronger choice in 3 areas. First, its associative engine supports free-form exploration across all loaded data, which analysts value for discovery work. Second, Qlik Talend Cloud adds data integration and movement, including SAP data extraction on the Premium plan, while Bold Data Hub, Bold BI’s ETL component, offers 48 connectors. Third, Qlik Predict offers built-in automated machine learning, while Bold BI forecasting uses exponential smoothing on line and spline charts.

What are Bold BI’s known limitations?

Bold BI is not the right fit for every team. Localization is available on-premises but not on the shared Cloud Edition. The AI Assistant queries one data source per conversation and cannot edit dashboards. Prompt to Dashboard generates exactly 6 widgets and works only on empty dashboards. Bold Data Hub transformations run in SQL code mode, without a visual modeling interface.

Which platform fits your organization?

The right choice depends on whether you are building analytics into a product or exploring data inside the enterprise.

Choose Bold BI if:

• You are embedding analytics in a SaaS product and want one instance to serve many tenants.
• You need white-labeling, custom domains, and zero vendor branding at no extra cost.
• You want pricing that does not grow per user or per GB of data loaded.
• You must self-host, including on Linux, Kubernetes, or in an air-gapped network, with the full feature set.

Choose Qlik Sense if:

• Your analysts rely on associative, free-form exploration across many data sources.
• You want data integration, analytics and AutoML from one vendor through Qlik Talend Cloud and Qlik Predict.
• Your organization already runs Qlik and has trained Qlik developers.

For a one-page feature summary, see the Bold BI Qlik Sense alternative page.

Other Qlik Sense Alternatives

While Qlik Sense remains a strong analytics platform, organizations evaluating embedded analytics often compare it against Bold BI, Tableau, Power BI, and Sisense based on deployment requirements, pricing model, embedded experience, and multi-tenant architecture.

How do you migrate from Qlik Sense to Bold BI?

Bold BI includes free, guided migration assistance on every edition. A typical Qlik migration follows 4 steps:

1. Inventory your Qlik apps, data connections, and Section Access security rules.
2. Connect the same sources using Bold BI’s 143 connectors, or load data through Bold Data Hub.
3. Rebuild dashboards in the drag-and-drop designer or with AI Copilot, and map Section Access rules to Bold BI row-level security.
4. Embed, brand, and publish inside your product, then retire the Qlik apps.

Start with the 30-day Bold BI free trial, no credit card required.

What results have Bold BI customers reported?

Organizations use Bold BI to reduce reporting overhead, improve customer-facing analytics experiences, and accelerate access to business insights.

Vialto Partners: Faster Reporting and Data-Driven Decision Making

Vialto Partners, a global mobility tax and consulting firm, needed a centralized analytics experience that could reduce manual reporting effort and improve visibility across business operations.

• Outcome: Reduced report generation time by 60% and accelerated decision-making cycles by 40%.
• How: Implemented interactive dashboards and self-service analytics to consolidate reporting and improve access to business insights.
• Why it matters: Teams spent less time preparing reports and more time acting on data, enabling faster and more informed decision-making across the organization.

Customer Feedback from G2

In addition to documented customer success stories, Bold BI is rated 4.9/5 on Capterra and 4.4/5 on G2.

One G2 reviewer highlighted the platform’s embedded analytics capabilities, multi-tenancy support, and ease of integration within SaaS applications:

“Finally, embedded analytics that get out of our way, at a fraction of the cost”

“Bold BI does the three things our product actually depends on, natively: embedding dashboards directly into our React app, connecting live to MySQL without an intermediate data layer, and keeping each client’s data cleanly isolated through built-in multi-tenancy. Coming from a prior platform where each of those was a fight, the difference has been night and day. The React SDK made embedding straightforward, and features that had eaten months of effort elsewhere came together in days. Support has been a standout too. The team is genuinely responsive and, depending on the complexity of the issue, will jump on a call with multiple engineers rather than trading tickets back and forth for weeks.”

By Barbara S. Source G2

Final thoughts

Both Bold BI and Qlik Sense are strong analytics platforms, but they serve different priorities. Qlik Sense is well suited for organizations focused on internal analytics and associative data exploration, while Bold BI is designed for embedded analytics, multi-tenancy, and customer-facing deployments.

As you evaluate platforms, consider deployment flexibility, scalability, tenant management, security, and long-term operational requirements. Review the latest vendor documentation and validate capabilities against your specific use cases before making a decision.

Ready to evaluate embedded analytics for your application? Start your free Bold BI trial today or schedule a personalized demo.

Frequently asked questions

1. Is Qlik Sense good for embedded analytics?
   Yes, but Qlik requires one Qlik Cloud tenant per customer, and anonymous public access starts on the Premium plan. Bold BI serves many tenants from one instance and includes white-labeling.
2. Is Bold BI cheaper than Qlik Sense?
   It depends on scale. Bold BI uses flat, application-based pricing, not per user or usage-metered. Qlik Cloud is priced by data capacity, starting at $300/month for 10 GB.
3. Can Bold BI run on-premises like Qlik Sense Enterprise?
   Bold BI On-Premises runs on Windows, Linux, Docker, and Kubernetes, including air-gapped networks, with the full feature set. Qlik’s self-hosted version runs on Windows servers.
4. Does Bold BI support white-labeling?
   White-labeling is included in every Bold BI edition, covering logo, colors, login page, emails, and custom domains, with no vendor branding.
5. What is Qlik Sense better at than Bold BI?
   Free-form data exploration through its associative engine. Qlik also offers data integration through Qlik Talend Cloud and automated machine learning through Qlik Predict on Premium.
6. Is Bold BI easier to learn than Qlik Sense?
   Bold BI needs no proprietary scripting: dashboards are built by drag-and-drop or with AI Copilot. Qlik Sense uses its load script syntax for custom data modeling.
7. How long does it take to migrate from Qlik Sense to Bold BI?
   It depends on how many apps, data models, and security rules you have. Bold BI includes free guided migration, and the 30-day trial lets you rebuild a sample Qlik app first.
8. Which AI features do Bold BI and Qlik Sense offer?
   Bold BI offers AI Copilot, AI Agent, and AI Assistant, with 500 AI credits per license per month. Qlik offers Qlik Answers, with automated machine learning on Premium.

Originally published at https://www.boldbi.com on October 14, 2026.

Bold BI vs. Qlik Sense: Embedded Analytics Compared was originally published in Bold BI on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR: The cheapest embedded analytics pricing model at 500 users is rarely the cheapest at 50,000 users. Whether pricing is tied to users, usage, capacity, or applications directly affects scalability, budgeting, and long-term profitability. Bold BI uses application-based licensing, helping organizations avoid per-user and per-viewer fees while planning for long-term growth.

Most embedded analytics pricing decisions are made based on current usage. The challenge is that embedded analytics costs rarely remain tied to current usage for long. As customer adoption grows, your pricing model matters more than your starting price.

Unlike traditional BI deployments that primarily support internal teams, embedded analytics is delivered directly to customers, partners, and external users. In many cases, the more successful your product becomes, the more analytics users you must support. A pricing model that charges for every user, every view, or every interaction can turn growth into a growing licensing expense.

The four embedded analytics pricing models

Different pricing models charge for different things. What matters most isn’t the starting price, but what drives your costs up over time.

The most important difference between these models is the metric that drives future costs. Before choosing a platform, organizations should understand how pricing behaves when analytics adoption expands from hundreds to thousands of users.

How popular embedded analytics vendors structure their pricing

Most embedded analytics vendors use similar pricing concepts, but apply them differently. The examples below are based on publicly available information as of October 2026 and may change over time.

• Bold BI: Uses application-based licensing, with pricing based on application and deployment requirements rather than per-user or per-viewer fees.
• Tableau: Tableau offers three licensing models for embedded analytics: role-based licensing (Creator, Explorer, and Viewer) for Tableau Cloud and Tableau Server, usage-based licensing for Tableau Cloud, measured in analytical impressions when external viewers access embedded content, and core-based licensing for Tableau Server.
• Power BI: For embedding analytics in customer-facing applications, Power BI is priced by capacity rather than per user. Organizations purchase capacity through A, EM, or Microsoft Fabric F SKUs. Microsoft is retiring Premium P SKUs in favor of F SKUs. When embedding analytics for your customers, end users do not require a Power BI license. Report authors and publishers typically require a Power BI Pro or Premium Per User (PPU) license.
• Qlik Sense: Qlik offers Qlik Sense in the cloud through its Qlik Cloud Analytics plans. The entry-level Starter plan includes a set number of users, while the Standard plan and above are priced by data capacity. Standard starts at $825 per month for 25 GB of data, billed annually. These are Qlik Cloud Analytics plans rather than embedded-specific pricing, so confirm embedding terms with Qlik. Qlik Sense Enterprise Client-Managed, the self-hosted version, isn’t priced on that page.
• Sisense: Sisense primarily offers custom pricing that varies by deployment, architecture, scale, and business requirements. Sisense offers a self-serve plan, while enterprise pricing is provided through a custom quote based on deployment requirements.

Because pricing models, packaging, and licensing terms can change over time, verify current information directly with vendors during your evaluation process.

How do embedded analytics costs change as you scale?

Pricing models often appear similar during early deployments. The differences become much more noticeable as adoption increases.

The example below uses illustrative pricing only and does not represent any vendor’s actual pricing.

Illustrative assumptions used below:

• Per-user pricing: $10 per user/month
• MAU pricing: $5 per monthly active user, with 40% active usage
• Capacity-based pricing: starts at $1,000/month and increases as additional capacity is required
• Flat or application-based pricing: hypothetical fixed cost of $2,500/month

Note: Application-based pricing quotes can still vary based on deployment type and scale tier requirements. The key difference is that pricing isn’t tied directly to individual user seats or viewer counts.

Three important patterns emerge:

• User-based pricing typically increases alongside customer growth.
• Usage-based pricing can reduce costs during early adoption but still scales with engagement.
• Capacity-based and application-based pricing often provide more predictable long-term costs.

Capacity-based and application-based pricing are not the same

While both models can remain cost-effective at high user volumes, they scale differently. With capacity-based pricing, costs are tied to platform resources and workloads. As usage increases, you may need to purchase additional capacity, move to higher tiers, or actively monitor utilization to maintain performance.

Application-based pricing focuses on the application rather than user counts or platform consumption. As a result, organizations can often expand analytics adoption without forecasting per-user licenses or usage credits. For businesses expecting significant customer growth, this difference can make long-term budgeting and cost forecasting easier.

Hidden costs that can affect embedded analytics pricing

Licensing is only one part of the total investment required for embedded analytics. Before comparing vendors, consider expenses that may not appear in the initial quote.

• Viewer licenses: Some vendors charge separately for dashboard viewers and creators.
• Overage charges: Additional fees may apply when usage exceeds contracted limits.
• Development and staging environments: Non-production environments may require separate licensing.
• Capacity upgrades: Increased demand may require moving to higher capacity tiers.
• Infrastructure expenses: Self-hosted and private-cloud deployments can introduce hosting and operational costs.
• : Branding customization may not always be included in base pricing.
• : Some vendors treat tenant isolation and management features as premium capabilities.

Evaluating these costs alongside licensing fees provides a more accurate understanding of total ownership costs.

Which embedded analytics pricing model is right for your business?

The best pricing model depends on your deployment strategy, growth expectations, and budgeting priorities.

Rather than choosing based solely on today’s requirements, evaluate which pricing model can continue supporting your organization as analytics adoption expands.

Questions to ask embedded analytics vendors before you buy

Before signing a contract, ask vendors the following questions and understand how the answers could affect your long-term costs.

How does pricing change if user adoption doubles or grows tenfold?

A pricing model that seems affordable at first may become significantly more expensive as adoption grows. Request pricing estimates at multiple growth stages to understand how costs scale over time.

What metric drives future pricing: users, activity, capacity, or deployments?

Understanding what triggers pricing increases helps determine whether costs align with your growth strategy or rise simply because more customers access analytics.

How are overages handled if usage exceeds contracted limits?

Some vendors apply additional fees, while others require plan upgrades. Clarifying this upfront can help prevent unexpected charges later.

Do you include multi-tenancy, white-labeling, and non-production environments?

These capabilities are often essential for embedded analytics deployments, but the base license may not include them.

Does pricing change based on deployment model or infrastructure requirements?

Cloud, managed private cloud, and self-hosted deployments can carry different cost implications. Understanding these differences helps organizations plan more effectively. The answers can reveal limitations and costs that may not be obvious during an initial vendor evaluation.

Why organizations choose Bold BI for predictable embedded analytics pricing

Organizations embedding analytics into customer-facing applications often look for pricing models that do not increase every time a new customer accesses a dashboard. Bold BI uses an application-based licensing approach rather than charging per user or per viewer. This allows organizations to expand analytics adoption without managing per-user or per-viewer licensing fees.

When evaluating embedded analytics pricing, several Bold BI characteristics are especially relevant:

• No per-user licensing fees: Customer growth does not automatically require additional user licenses.
• No per-viewer licensing fees: Organizations can expand dashboard access without managing viewer-based costs.
• Licensed by application: is based on the application and requirements rather than individual seat counts.
• Embedding included: are included as part of the platform.
• Multi-tenancy support: Designed to support SaaS and customer-facing analytics deployments.
• Consistent capabilities across editions: Cloud, Managed Private Cloud, and On-Premises deployments include the same core feature set.

One consideration is that Bold BI does not publish a fixed public price list. Organizations typically request a customized quote based on deployment type and scale tier requirements.

However, application-based pricing isn’t necessarily the lowest-cost option in every scenario. Organizations supporting a small internal audience with no plans to embed analytics externally may find a traditional per-user model has a lower initial cost. The best pricing model depends on how you’ll deploy analytics and how adoption is expected to grow.

Important: Don’t interpret application-based pricing as fixed regardless of scale. Quotes may vary by deployment type and scale-tier requirements. The key difference is that pricing is not directly tied to individual user seats or viewer counts.

How to build an embedded analytics pricing strategy that scales

The right embedded analytics pricing model should support growth without creating licensing complexity as adoption increases.

When evaluating vendors, compare pricing at multiple growth stages, understand what drives future cost increases, and account for potential hidden expenses. Looking beyond the initial subscription cost helps create a more accurate picture of long-term value.

For organizations embedding analytics into customer-facing applications, Bold BI® offers application-based licensing that avoids per-user and per-viewer fees while making it easier to forecast analytics costs as adoption grows. Whether you’re evaluating embedded analytics for a SaaS platform, customer portal, or partner application, Bold BI provides flexible deployment options and scalable analytics capabilities designed for long-term growth.

Ready to see how scalable embedded analytics pricing could work for your application? Start a free trial of Bold BI or request a personalized demo to explore the best pricing approach for your growth strategy.

Frequently asked questions

1. Does Bold BI charge per user?

No. According to Bold BI’s pricing page, there is no per-user or per-viewer fee. Quotes are based on deployment type and scale requirements.

2. How do I estimate embedded analytics costs?

Evaluate pricing at multiple growth stages, estimate expected adoption levels, consider deployment requirements, and account for additional expenses such as infrastructure, staging environments, and overage charges

3. Is MAU pricing cheaper than per-user pricing?
It can be when only a portion of users actively access analytics each month. However, costs can still increase significantly as engagement and adoption grow.

4. What is the most common embedded analytics pricing model?
There is no single standard. Per-user and role-based licensing remains widespread for internal BI, while embedded analytics offerings increasingly use capacity-based, usage-based, or application-based models. Compare vendors on what drives future costs rather than on which model is most common.

5. Does Bold BI include embedded analytics capabilities?
Yes. Embedded analytics capabilities are included as part of the Bold BI platform and do not require a separate embedding product.

6. Can Bold BI be deployed on-premises or in private cloud environments?
Yes. Bold BI supports cloud, managed private cloud, and on-premises deployments while maintaining the same core feature set across editions.

Originally published at https://www.boldbi.com on October 12, 2026.

Embedded Analytics Pricing Models Compared | Bold BI was originally published in Bold BI on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR: AI is making analytics faster, smarter, and more accessible. But as organizations increasingly rely on AI-generated insights, trust has become a critical challenge. If users can’t understand what changed, who made the change, or whether the analytics environment is properly governed, confidence in those insights quickly declines. AI audit trails help solve this problem by providing transparency into activities, changes, and governance events across analytics environments. In this blog, you’ll learn how AI audit trails strengthen trust, support governance, and prepare organizations for the future of AI-powered analytics.

Introduction

Your AI assistant flags a 12% drop in customer retention and recommends immediate action. Before anyone acts, someone asks a critical question: Did anyone change the retention formula, dashboard, or permissions last week? If your team cannot answer quickly, the insight stalls. Worse, a decision could move forward based on a broken dashboard, outdated configuration, or unauthorized change.

This is one of the biggest challenges in AI-powered analytics . Organizations need more than intelligent insights. They need confidence in the analytics environment that produced them. That growing need for trust is making auditability a critical part of modern analytics.

An AI audit trail helps your team understand what changed, who made the change, when it happened, and whether the change was authorized. By creating a traceable history of activity across analytics environments, audit trails help organizations investigate unexpected results, strengthen governance, and improve decision-making confidence.

In this blog, you’ll learn what an AI audit trail is, why it matters, and how it helps build trust in AI-powered analytics.

What Is an AI Audit Trail?

is a chronological record of activities and changes that may influence analytics outcomes and AI-assisted decision-making. It helps organizations understand what changed, who performed an action, when it occurred, and whether the action aligns with established governance policies.

It captures information such as user actions, dashboard modifications, permission updates, tenant activities, schedules, and administrative events, creating a verifiable record of activities across the analytics environment.

Unlike a traditional audit log that records individual system events, an AI audit trail provides the broader context needed to understand how changes, actions, and AI-driven processes may have contributed to a particular insight or recommendation.

As AI becomes more embedded in analytics workflows, audit trails help organizations trace activities, review decisions, and validate the environment behind AI-generated outputs.

Let’s explore the key challenges preventing organizations from fully trusting AI-generated insights and why auditability has become more important than ever.

The Hidden Challenges Behind AI-Generated Insights

As organizations increase their reliance on AI-powered analytics, several challenges can make it difficult to fully trust the insights being generated.

Taken together, these challenges highlight a common theme: organizations need greater visibility and control over their analytics environments to confidently trust and act on AI-generated insights.

So, how can organizations overcome these challenges and establish greater confidence in AI-powered analytics? Let’s explore how AI audit trails help bridge the gap between insights and trust.

How Audit Trails Build Confidence in AI-Generated Insights

An audit trail is much more than a record of activities. It is a foundation for building confidence in analytics environments. As organizations increasingly rely on AI-generated insights, they need visibility into the actions, changes, and events that may influence analytics outcomes. Rather than relying on assumptions, audit trails provide the evidence needed to understand and validate the environment behind AI-assisted recommendations.

To build confidence in AI-generated insights, organizations should be able to answer four fundamental questions:

Who Performed the Action?

Organizations should be able to trace activities back to specific users, administrators, or teams. Whether a dashboard was modified, permissions were updated, or administrative settings were changed, knowing who performed the action strengthens accountability and simplifies investigations.

What Changed?

Understanding what was modified is just as important as knowing who made the change. Organizations should have visibility into dashboard updates, permission changes, configurations, schedules, and other analytics assets that may influence insights.

When Did It Happen?

Time-stamped records provide critical context when reviewing activities or investigating unexpected outcomes. By maintaining a chronological history of events, organizations can quickly establish what happened and in what sequence.

Was the Action Authorized?

Not every change is a concern, but every change should be verifiable. Organizations need confidence that activities align with established governance policies, security controls, and access permissions.

By answering these questions, audit trails help organizations move from assumptions to evidence. Instead of treating analytics as a black box, teams can trace activities, validate changes, and better understand the environment behind AI-generated insights.

This visibility delivers several important benefits:

• Greater transparency: Audit trails provide visibility into dashboard updates, permission changes, user activities, and system events. This helps organizations understand how their analytics environments evolve over time.
• Improved accountability: Recorded actions are linked to a user and timestamp, making it easier to understand ownership and responsibility when changes occur.
• Stronger governance: Organizations gain better oversight across dashboards, settings, permissions, and administrative actions, helping maintain governance standards at scale.
• Faster investigations: Instead of spending days asking who changed a dashboard, KPI, or permission setting, teams can quickly filter audit records by user, action, event type, and timestamp to identify the cause, often in minutes.
• Support for responsible AI adoption: Responsible AI requires more than intelligent algorithms. It requires analytics environments that are transparent, accountable, and governed. Audit trails help provide that foundation.

To build trust effectively, organizations must understand which activities, changes, and governance events should be recorded in the first place.

What Should an Analytics-Focused AI Audit Trail Capture?

An effective AI audit trail should capture the activities and changes that can influence analytics outcomes and AI-generated insights. By maintaining visibility across the analytics environment, organizations can better investigate unexpected results, strengthen governance, and validate AI-driven recommendations.

• User activity: Track user logins, dashboard views, exports, comments, and other interactions to understand how analytics assets are being accessed and used. User-level visibility helps establish accountability and supports activity monitoring.
• Dashboard and analytics changes: Monitor dashboard edits, widget updates, KPI modifications, schedule changes, and report configuration updates. These changes can directly affect the insights and recommendations users receive.
• Permission and access changes: Record role assignments, permission updates, user management activities, and authentication-related changes. Maintaining visibility into access controls is essential for security and governance.
• Administrative and system events: Track administrative actions such as settings updates, tenant management activities, licensing changes, and system configuration changes that may impact the analytics environment.
• Tenant and governance events: For enterprise and multi-tenant deployments, audit trails should record tenant-level activities, cross-tenant administrative actions, governance events, and policy-related changes to help maintain oversight at scale.
• Audit metadata: Every event should include supporting details such as the user, timestamp, action performed, affected resource, and event type. This context makes investigations and audits more effective.

It is important to understand the scope of an audit trail. Bold BI® audit trail focuses on configuration and structural activities such as dashboard updates, user actions, permission changes, schedules, tenant activities, and administrative events. Audit records are designed to provide visibility into operational and governance activities that affect the analytics environment.

Understanding the Broader AI Audit Trail Landscape

As AI adoption grows, organizations are expanding auditability beyond traditional analytics activities. In some AI systems, audit trails may also capture prompts, model interactions, generated outputs, approval workflows, and automated actions. These records help organizations improve traceability across the broader AI lifecycle.

However, auditability requirements vary depending on how AI is implemented. In analytics platforms, trust often depends not only on AI interactions themselves but also on the environment that influences AI-generated insights. Changes to dashboards, metrics, permissions, schedules, governance settings, and administrative configurations can directly affect the recommendations users receive.

For this reason, organizations should view AI auditability as a combination of two complementary layers:

• AI lifecycle auditability focused on prompts, outputs, approvals, and AI-driven actions.
• Analytics environment auditability focused on dashboards, permissions, configurations, governance controls, and user activities that shape analytics outcomes.

Together, these capabilities help organizations strengthen transparency, accountability, and trust in AI-powered decision-making. This article focuses primarily on the analytics environment layer because changes to dashboards, permissions, configurations, and governance settings can directly influence the insights users receive.

AI Audit Trail vs Audit Log vs AI Governance

Although these terms are often used interchangeably, they serve different purposes in modern analytics environments.

In simple terms, audit logs record what happened, AI audit trails explain how events influence outcomes, and AI governance defines the rules that guide responsible AI use.

Why Log Retention and Immutability Matter

Trust depends on reliable records. Audit trails provide value only when historical events remain available, accurate, and protected from unauthorized modification. Bold BI® stores audit records securely, supports exporting logs, and maintains immutable audit records. Retention follows your database configuration policies, helping organizations preserve a trustworthy history of analytics activity for investigations, governance reviews, and operational audits.

Now let’s look at real-world scenarios where audit trails help organizations strengthen trust in AI-generated insights.

Real-World Scenarios Where Audit Trails Make a Difference

Audit trails become even more valuable as analytics expands across SaaS applications, embedded experiences, enterprise deployments, and multi-tenant environments. The following examples show how organizations use auditability to strengthen trust, improve governance, and investigate unexpected analytics outcomes.

Embedded Analytics: Supporting Transparency Across Customer Portals

• cenario: A customer notices a significant change in a KPI displayed within an embedded analytics dashboard.
• Challenge: Without visibility into recent activities, the organization struggles to determine whether the change resulted from business performance or a dashboard modification.
• How audit trails help: Audit records create a clear history of changes across embedded analytics experiences, making it easier to determine whether a KPI shift reflects actual business performance or a recent dashboard modification. This helps organizations explain outcomes and strengthen customer trust.

Multi-Tenant Analytics: Scaling Governance Across Environments

• Scenario: A managed service provider supports analytics for several customer environments within a shared deployment.
• Challenge: Administrators need to monitor activities within individual tenants while maintaining oversight across the entire deployment.
• How audit trails help: Tenant-level, multi-tenant, and User Management Server (UMS) audit visibility help administrators monitor activities across environments while maintaining oversight at scale. This makes it easier to support multiple customers, business units, or regions from a single analytics deployment.

Now that we’ve explored where audit trails deliver value in practice, let’s look at some practical steps organizations can take to implement auditability effectively across their analytics environments.

Practical Tips for Implementing an AI Audit Trail

Building an effective AI audit trail isn’t just about collecting activity records. The goal is to create a transparent and governed analytics environment that supports trust, accountability, and responsible AI adoption.

Organizations can strengthen their auditability strategy by following these practices:

• Define clear audit requirements before deploying AI-powered analytics initiatives.
• Monitor dashboard updates, permission changes, and user activities consistently.
• Establish ownership and accountability for analytics assets and governance processes.
• Review audit records regularly to identify unusual activities and potential risks.
• Integrate audit information with existing security, governance, and operational workflows.
• Maintain visibility across embedded analytics, SaaS deployments, and multi-tenant environments.
• Use APIs and automation to streamline monitoring and governance activities.

By approaching auditability as an ongoing governance practice rather than a compliance exercise, organizations can build greater confidence in their analytics environments while supporting long-term AI adoption.

As organizations strengthen auditability practices today, they also position themselves for the next generation of AI-powered analytics.

AI Audit Trail and Regulatory Readiness

As AI adoption grows, organizations face increasing expectations around transparency, accountability, and governance. Frameworks such as the EU AI Act, NIST AI Risk Management Framework, and ISO/IEC 42001 emphasize traceability and oversight throughout the AI lifecycle. Many emerging AI governance frameworks emphasize traceability across both the AI lifecycle and the systems that influence AI-generated outcomes. Audit trails help organizations prepare for these evolving expectations by providing the visibility and traceability needed to demonstrate accountability.

The Future of Governed and Agentic Analytics

Analytics is rapidly evolving from dashboards that report what happened to AI systems that explain, recommend, and even automate actions.

As organizations adopt AI assistants and agentic analytics, trust will depend on more than intelligent recommendations. Businesses will need visibility into how insights were generated, what changes influenced them, and whether recommendations can be traced and validated.

At the same time, governed AI will increasingly rely on trusted semantic layers that provide shared business definitions and governed metrics across the organization. Trusted semantic layers help ensure that both AI systems and your teams rely on the same governed definitions, metrics, and calculations. This shared business context helps AI-generated insights remain consistent, explainable, and aligned with organizational standards.

As AI agents begin taking actions instead of simply generating recommendations, organizations will need visibility into those actions, the systems involved, and the governance controls surrounding them. Trust will depend not only on what an AI agent suggests, but also on what it does.

Together, semantic layers and AI audit trails create a stronger foundation for AI governance by helping organizations validate insights, maintain accountability, and build confidence in AI-powered decision-making.

Where Bold BI Fits into the Future of Trusted Analytics

As organizations adopt AI-powered analytics, trust increasingly depends on visibility, accountability, and governance. Generating insights is only part of the challenge. Teams also need to understand what changed, who made the change, and whether the analytics environment supporting those insights remains properly governed.

With Bold BI, your team can:

• Monitor dashboard updates, user activities, permission changes, schedules, tenant operations, and administrative events through Bold BI audit trail.
• Filter audit records by user, action, event type, and date to investigate unexpected changes and identify their source.
• Support governance across tenant-level, multi-tenant, and User Management Server (UMS) environments in self-hosted deployments for enterprise-scale oversight.
• Export audit records and integrate with monitoring workflows through APIs, webhooks, and SIEM platforms such as Splunk, Microsoft Sentinel, and AWS CloudWatch.
• Maintain visibility into operational and governance activities across analytics environments.
• Use AI-powered analytics capabilities while maintaining appropriate governance and visibility into analytics operations.
• Use AI capabilities such as AI Copilot, AI Assistant, AI Agent, Prompt-to-Dashboard, Smart Narrations, and AI Credits Management within a governed analytics environment.
• Deploy across cloud, self-hosted, Docker, Kubernetes, and on-premises environments while applying governance controls appropriate to each deployment model.

By combining auditability, governed AI, enterprise scalability, and flexible deployment options, Bold BI helps teams make decisions with greater confidence.

As trust becomes a defining factor in analytics adoption, organizations that invest in transparency, governance, and responsible AI practices will be better positioned to unlock the full value of AI-generated insights.

Conclusion

AI helps organizations uncover insights faster, automate analysis, and make more informed decisions. However, the success of AI-powered analytics depends on more than advanced algorithms and intelligent recommendations. It depends on trust.

Organizations need confidence that the analytics environments supporting AI-generated insights are transparent, governed, and accountable. Without visibility into user activities, dashboard updates, permission changes, and system events, even valuable insights can be questioned.

This is why AI audit trails are becoming an essential part of modern analytics strategies. By improving transparency, strengthening governance, and creating clear accountability across analytics environments, audit trails help organizations bridge the gap between AI-generated insights and trusted decision-making.

As AI-native analytics, embedded analytics, SaaS analytics, enterprise multi-tenancy, and agentic analytics continue to evolve, auditability will play an increasingly important role in ensuring analytics remains not only intelligent but also trustworthy.

Ready to build trusted analytics?

Whether you’re delivering internal BI, embedded analytics, customer-facing dashboards, or AI-powered insights, helps your team strengthen governance, improve accountability, and make decisions with greater confidence.

• Start a free trial (No credit card required).
• Request a live demo.

Frequently Asked Questions

1. What is an AI audit trail ?

An AI audit trail is a documented record that helps organizations trace activities, decisions, changes, and events related to AI-assisted workflows and analytics environments. Depending on the implementation, it may include AI interactions, governance activities, user actions, and system changes that influence outcomes.

2. Why are AI audit trails important?

AI audit trails improve transparency, accountability, and governance, helping organizations build trust in analytics and AI-assisted decision-making

3. How do AI audit trails build trust in AI-generated insights?

They provide visibility into user activities, dashboard updates, permission changes, and other events that may influence analytics outcomes.

4. What should an AI audit trail track ?

It should track dashboard edits, user activity, permission updates, administrative actions, system changes, and governance-related events .

5. Why are AI audit trails important for embedded analytics and SaaS applications ?

They help organizations maintain transparency across customer-facing analytics experiences, making it easier to investigate issues, validate insights, and build customer trust .

6. How does Bold BI Audit Trail support analytics governance?

Bold BI Audit Trail helps organizations monitor dashboard changes, user activities, permission updates, and administrative actions, providing greater visibility and accountability across analytics environments.

7. Can Bold BI Audit Trail help organizations operating in multi-tenant environments?

Yes. Tenant-level, multi-tenant, and User Management Server (UMS) audit visibility are available in self-hosted (on-premises) Bold BI deployments from version 8.1 onward. These capabilities help administrators monitor activities across tenants and maintain governance at scale.

8. Does Bold BI Audit Trail capture dashboard data or analytics results?

Bold BI’s audit trail records configuration and operational events such as dashboard modifications, user actions, permission changes, schedules, tenant activities, and administrative events. Organizations should review their implementation and audit policies to determine what information they retain in their environment.

Originally published at https://www.boldbi.com on September 25, 2026.

AI Audit Trail: Building Trust and Governance in Analytics was originally published in Bold BI on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR: Your warehouse reports a 94% on-time delivery rate. Transportation reports 87%. Both are right, and that’s the problem. When teams measure the same KPI differently, no dashboard can settle the argument. This guide shows how to define logistics KPIs once, with formulas, owners, and business rules, then track them across delivery, warehouse, and transportation dashboards.

Introduction

Logistics dashboards and KPIs are supposed to give every team one view of operations. Yet in a Monday review, the warehouse team might report a 94% on-time delivery rate while transportation reports 87%. Both numbers are correct. One team measured against the carrier’s ETA, while the other measured against the date promised to the customer. The problem isn’t the dashboard. It’s the KPI definition.

This challenge is one reason why logistics dashboards and KPIs often fail to provide a single, trusted view of performance. Data flows in from warehouse management systems, transportation platforms, carrier feeds, telematics systems, and spreadsheets maintained by different teams. Without agreed definitions, even a well-designed dashboard can produce conflicting results and make decision-making harder. Bold BI® lets teams define KPI calculations once and reuse them across dashboards.

This guide starts with the fix, a set of standard KPI definitions, then shows three dashboards that put them to work.

Why KPI definitions matter more than dashboard design

Many dashboard projects focus on charts, filters, and visual design. In practice, the harder problem is agreeing on what each number means. A KPI definition is a documented explanation of what a metric measures, how it is calculated, and which business rules govern its use.

The following logistics KPI definitions provide a foundation for building reliable dashboards and measuring performance consistently across teams.

On-time delivery rate

• Formula: On-time deliveries ÷ Total deliveries × 100
• Data Source: TMS, carrier feed
• Owner: Logistics operations
• Recommended Rule: Use customer-promised date, not carrier ETA.

Warehouse throughput

• Formula: Total units processed ÷ Period
• Data Source: WMS
• Owner: Warehouse manager
• Recommended Rule: Use a consistent unit of measure across facilities.

Labor productivity

• Formula: Units processed ÷ Direct labor hours
• Data Source: WMS, labor system
• Owner: Warehouse manager
• Recommended Rule: Use the same unit as throughput; count direct labor hours only.

Fleet utilization rate

• Formula: Active vehicle hours ÷ Available vehicle hours × 100
• Data Source: Telematics system
• Owner: Transportation manager
• Recommended Rule: Exclude vehicles that are out of service for planned maintenance.

Successful delivery rate

• Formula: Successful deliveries ÷ Total deliveries × 100
• Data Source: TMS
• Owner: Logistics operations
• Recommended Rule: Define successful as no delivery exceptions, damage, or returns.

Picking accuracy rate

• Formula: Correctly picked orders ÷ Total orders picked × 100
• Data Source: WMS
• Owner: Warehouse manager
• Recommended Rule: Track picking errors separately from fulfillment delays.

Capacity utilization

• Formula: Used capacity ÷ Available capacity × 100
• Data Source: WMS
• Owner: Warehouse manager
• Recommended Rule: Use the same capacity calculation across facilities.

Other commonly tracked logistics KPIs include OTIF (On-Time In-Full), perfect order rate, inventory accuracy, dock-to-stock time, order cycle time, and cost per shipment.

For example, an on-time delivery KPI definition might include:

• Formula: (On-time deliveries ÷ Total deliveries) × 100.
• Data source: Transportation Management System (TMS) and carrier tracking data.
• Owner: Logistics operations team.
• Refresh schedule: Daily.
• Business rule: Measure against the customer-promised delivery date, not the carrier ETA.

Once KPI definitions are standardized, dashboards become trusted decision-making tools rather than competing versions of the truth.

3 logistics dashboards and KPIs: Examples by function

The following logistics dashboard examples cover three critical operational functions: delivery, warehousing, and transportation. Together, they provide visibility into how goods move through the logistics lifecycle.

Distributor delivery performance dashboard

The Distributor Delivery Performance Dashboard tracks delivery reliability, distributor performance, and service-level compliance. By combining shipment data, delivery timelines, and customer feedback, it provides a centralized view of delivery operations.

Who uses it: Logistics managers and distribution teams, daily to catch late shipments and weekly to review distributor performance.

The KPI challenge

Distributor comparisons become unreliable when teams define delivery performance differently. For example, one team may calculate on-time performance using promised delivery dates, while another uses carrier ETAs.

Recommended definition: Calculate on-time delivery rate using the customer-promised delivery date rather than the carrier ETA.

Key KPIs include:

• On-time delivery rate: Measures the percentage of deliveries completed on time.
• Successful delivery rate: Measures the percentage of deliveries completed without delivery exceptions, damage, or returns.

Formula: (Successful deliveries ÷ Total deliveries) × 100

Supporting metrics

• Average delivery time: Measures the average time required to complete deliveries.
• Total deliveries: Tracks overall delivery volume across distributors.
• On-time deliveries: Shows the number of deliveries completed within the agreed timeframe.

What the dashboard helps answer

• Which distributors consistently meet delivery commitments?
• Which regions experience the highest delivery delays?
• Which distributors require additional performance reviews?
• Which shipments require investigation?

What to do when performance changes

If the on-time delivery rate declines, drill down by region, then by distributor, and finally to individual shipments to identify the source of delays.

Bottom line: Distributor rankings only mean something when every team uses the same definition of on-time delivery. Explore the Distributor Delivery Performance Dashboard for an example of how these metrics can be monitored in practice.

Warehouse performance dashboard

The Warehouse Performance Dashboard provides visibility into fulfillment operations, workforce productivity, warehouse capacity, and operating costs. This dashboard helps teams track key warehouse KPIs such as throughput, labor productivity, and capacity utilization.

Who uses it: Warehouse managers and shift supervisors, daily to manage workload and weekly to compare facilities.

The KPI challenge

Warehouse teams often compare performance across facilities, but those comparisons become misleading when throughput, productivity, and utilization are measured differently. Warehouse throughput should use the same unit of measure, whether orders, order lines, or units processed, across all facilities.

For example, a facility processing fewer but larger orders may appear less productive than another facility even when it operates more efficiently.

Key KPIs include:

• Warehouse throughput: Measures the volume of goods or orders processed during a specific period.
• Labor productivity: Measures output per labor hour, such as orders processed or order lines picked per hour.
• Picking accuracy rate: Measures the percentage of orders picked without errors.

Formula: (Correctly picked orders ÷ Total orders picked) × 100

• Capacity utilization: Measures the percentage of available warehouse capacity currently in use.

Formula: (Used capacity ÷ Available capacity) × 100

Supporting metrics

• Total orders: Measures the volume of orders processed by the warehouse.
• Unfulfilled orders: Tracks orders that have not yet been completed.
• Warehouse operating expense: Tracks warehouse operating costs over time.

What the dashboard helps answer

• Which bottlenecks are affecting fulfillment speed?
• How much volume is being processed over time?
• Which shifts or teams are most productive?
• Where is warehouse capacity becoming constrained?
• How are operational costs changing?

What to do when performance changes

If throughput drops, check labor productivity (are people slower?), capacity utilization (is space constrained?), and unfulfilled orders (is a backlog building?). The metric that moved first usually points to the bottleneck.

Bottom line: Standardized warehouse KPIs improve performance comparisons across facilities. Explore the Warehouse Performance Dashboard for an example of how these metrics can be measured across fulfillment operations.

Fleet performance analysis dashboard

The Fleet Performance Analysis Dashboard covers the transportation stage of logistics, showing how goods move between warehouses, distributors, and customers.

Who uses it: Transportation and fleet managers, daily to plan dispatch and monthly to review fleet costs.

The KPI challenge

Fleet data is often managed separately from warehouse and delivery systems, making it difficult to evaluate transportation performance using the same standards applied elsewhere in the supply chain.

For example, some teams count every vehicle on the books, including those in the shop, which can make fleet utilization appear lower than it actually is. Fleet utilization is most effective when measured using active operating hours divided by available operating hours, excluding vehicles that are out of service for planned maintenance.

Key KPIs include:

• Fleet utilization rate: Tracks how effectively fleet assets are being used.

Formula: Active vehicle hours ÷ Available vehicle hours × 100

• Fuel consumption rate: Monitors fuel usage across vehicles.

Formula: Fuel used ÷ Distance traveled

Supporting metrics

• Distance traveled: Measures the total distance covered by the fleet.
• Average vehicle speed: Provides insight into route and transportation performance.

What the dashboard helps answer

• Which vehicles are underutilized?
• Where is fuel consumption increasing?
• Which vehicles or routes use the most fuel?

What to do when performance changes

If fleet utilization drops, review vehicle activity, route assignments, and operating schedules to identify underused assets and inefficiencies.

Bottom line: Transportation metrics are most useful when they follow the same KPI definitions used across delivery and warehouse operations. Explore the Fleet Performance Analysis Dashboard for an example of how fleet metrics can support broader operational visibility.

Where logistics dashboards go wrong

Even well-designed dashboards can fail if the underlying data and KPIs are not governed effectively.

Too many KPIs

Problem: Teams track every available metric, causing dashboards to become cluttered and difficult to use.

Fix: Limit each dashboard to five to seven KPIs tied to a specific decision. For additional guidance, see our article on 10 Best Practices for Designing Powerful Dashboards.

Undocumented definitions

Problem: KPI definitions exist informally and change from team to team.

Fix: Document formulas, business rules, owners, and data sources, and review them regularly.

Data refresh expectations

Problem: Users assume dashboards always contain the latest data.

Fix: Display whether a dashboard uses live queries or scheduled refreshes and show when the data was last updated.

Disconnected systems

Problem: Warehouse platforms, transportation systems, distributor portals, and telematics applications often operate independently. Without data integration, organizations struggle to form a complete view of operational performance.

Fix: Consolidate warehouse, transportation, carrier, and operational data into a unified analytics environment so teams can monitor performance end to end.

Building governed logistics dashboards with Bold BI

Defining KPIs is only the first step. Bold BI helps organizations apply those definitions consistently across logistics dashboards while maintaining governance and security.

Define KPI calculations once

Define a calculation such as on-time delivery rate once at the data-source level and reuse it across every dashboard. Update it in one place, and every dashboard reflects the change automatically.

Get alerted when a KPI slips

Configure alerts to notify teams when KPIs cross a threshold, for example when on-time delivery falls below 95%.

Share dashboards with distributors and customers

Dashboards can be embedded into customer, distributor, or carrier portals, enabling stakeholders to access logistics insights within the tools they already use.

Secure operational data

Logistics teams and stakeholders often need different levels of access to operational data. Row-level security ensures users only see the shipments, facilities, customers, or regions relevant to them.

Support different refresh requirements

Logistics data arrives from multiple systems that refresh at different intervals. Bold BI supports both live-query and scheduled-refresh approaches, allowing teams to balance data freshness with performance and operational requirements.

Deploy according to business requirements

Some organizations need logistics data to remain within their own environment. Bold BI On-Premises lets teams run analytics on their own infrastructure while maintaining visibility across warehouse, transportation, and operational data sources.

Turn KPI definitions into confident decisions

The three dashboards in this guide share one lesson: a dashboard is only as reliable as the KPI definitions behind it. When on-time delivery rate, warehouse throughput, labor productivity, and fleet utilization mean the same thing to every team, logistics leaders can act on the numbers instead of debating them.

Bold BI® helps teams apply KPI definitions consistently across dashboards and data sources, creating a trusted foundation for operational decision-making. Want logistics dashboards your whole team trusts? Start your free trial of Bold BI and put these KPI definitions to work.

Frequently asked questions

1. What is a logistics dashboard?

A logistics dashboard is a business intelligence tool that consolidates data from transportation, warehousing, fulfillment, inventory, and distribution systems into a single view. It helps teams monitor performance, track KPIs, identify bottlenecks, and make more informed operational decisions.

2. What is a logistics KPI?

A logistics KPI (Key Performance Indicator) is a measurable metric used to evaluate the efficiency, reliability, and effectiveness of logistics operations. Common examples include on-time delivery rate, warehouse throughput, labor productivity, and fleet utilization rate.

3. What logistics KPIs should organizations define first?

Start with on-time delivery rate, warehouse throughput, labor productivity, capacity utilization, and fleet utilization rate. Once those metrics are stable, add OTIF and perfect order rate.

4. How should on-time delivery rate be calculated?

On-time delivery rate = (On-time deliveries ÷ Total deliveries) × 100. Use the customer-promised date, not the carrier ETA, across all teams.

5. What is warehouse throughput?

Warehouse throughput measures the volume of goods, units, or orders processed during a specific period and helps organizations evaluate warehouse efficiency and capacity.

6. Why does fleet utilization matter?

Fleet utilization shows how much available vehicle time is actually spent in use. Low utilization may indicate excess vehicles, inefficient route planning, or poor asset allocation.

7. What is OTIF?

OTIF (On-Time In-Full) measures the percentage of orders delivered on time and in the correct quantity. It’s stricter than on-time delivery rate because a late or incomplete order counts as a miss.

Originally published at https://www.boldbi.com on October 9, 2026.

3 Logistics Dashboards and KPIs for Visibility | Bold BI was originally published in Bold BI on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR: Bold BI® offers four AI experiences. AI Copilot helps authors build dashboards, AI Agent helps viewers explore them, AI Assistant brings conversational analytics into applications, and the Bold BI MCP Tool lets compatible AI platforms discover, inspect, query, and export Bold BI content, read-only. Choose by where users work and what they need to do.

Which Bold BI AI feature should we use? Teams ask because there are four, including the Bold BI MCP Tool, and choosing the wrong one can lead to an AI feature people never use. Dashboard authors, analytics consumers, application users, and developers all interact with data differently, so each group benefits from a different experience.

Each option supports a specific workflow, from dashboard authoring and exploration to embedded analytics and AI-assisted operations. This guide compares the four AI experiences by where they live, who uses them, and what they can and can’t do, so you can choose the right one for your organization.

Meet the four AI experiences in Bold BI

Before comparing individual capabilities, it’s helpful to understand where each experience fits.

Rather than competing with each other, these capabilities support different stages of analytics, from dashboard authoring and exploration to embedded analytics and AI-assisted operations.

How to choose the right Bold BI AI tool

Once you understand each option’s purpose, the decision becomes much simpler.

Build dashboards faster

AI Copilot helps dashboard authors build and edit widgets with natural-language prompts, reducing manual dashboard authoring.

Best for: Dashboard development and rapid prototyping.

Get answers without leaving the dashboard

AI Agent helps dashboard viewers ask questions about the open dashboard, such as trends, counts, and performance metrics, without changing its widgets.

Best for: Analytics consumers who need deeper insights without leaving the dashboard they are already using.

Deliver conversational analytics inside applications

AI Assistant allows organizations to bring conversational analytics directly into embedded and customer-facing applications.

Users can ask questions about their data, explore metrics, and continue analytical conversations without leaving the application.

Best for: Embedded analytics and customer-facing AI experiences.

Work from existing AI platforms

The Bold BI MCP Tool enables compatible AI platforms such as Claude, ChatGPT, GitHub Copilot, and VS Code to read, query, and export analytics resources, read-only, through natural-language requests.

Instead of manually navigating analytics resources or writing API calls, users can work directly from their preferred AI environment.

Best for: Developers, analysts, and internal teams already using AI-powered tools.

Bold BI MCP Tool vs. REST APIs vs. AI Assistant

Teams evaluating MCP frequently ask how it differs from traditional APIs and embedded AI experiences.

REST APIs remain the preferred option when building direct integrations.

AI Assistant is designed for people interacting with analytics.

The Bold BI MCP Tool serves a different purpose by enabling AI platforms to work with analytics resources using a standardized protocol and natural-language requests.

Simply put, AI Assistant is designed for people, while MCP is designed for AI-assisted workflows.

What makes the Bold BI MCP Tool different?

Model Context Protocol (MCP) is an open standard that lets AI applications connect to and use external tools and systems. Learn more in this documentation.

With the Bold BI MCP Tool, compatible AI platforms can access analytics resources through controlled permissions and natural-language interactions.

Depending on deployment and access configuration, organizations can use MCP-enabled workflows to work with resources such as:

The MCP Tool offers more than 50 tools at the time of writing. It is read-only: it discovers, inspects, queries, and exports content, and never creates, edits, or deletes it. It runs with the permissions of the user the API key belongs to.

The key advantage is that MCP extends beyond chat experiences and enables AI-assisted operational workflows.

For example, organizations may use MCP-enabled AI platforms to:

• Review dashboard access permissions
• Identify analytics dependencies
• Audit analytics delivery configurations
• Export analytics information for review
• Inspect governance settings

These workflows can help teams manage analytics environments without requiring users to manually navigate every administrative area.

Why some teams use both AI Assistant and MCP

Choosing between AI Assistant and MCP is not always necessary. You can use both because they solve different problems.

For example:

• Customers interact with embedded analytics using AI Assistant.
• Data teams perform governance and audit tasks using MCP-enabled AI tools.
• Developers access documentation and analytics resources through their preferred AI platforms.
• Dashboard creators accelerate development with AI Copilot.

This approach lets each audience work in the environment that best matches its workflow.

Example AI analytics scenarios

These are hypothetical scenarios, not customer results. They show how Bold BI AI features can support common business needs.

Sales industry: Retrieving customer order insights with AI Assistant

• Scenario: A sales manager needs quick access to customer order metrics from a sales data source and wants answers without creating analytics or writing queries.
• Challenge: Finding order information often requires navigating datasets, building visualizations, or relying on technical teams to retrieve the data.
• How AI Assistant helps: The sales manager selects the Sales Analysis Data datasource and asks, “Show me the number of customer orders.” AI Assistant interprets the natural language request and returns the answer as a visual, grid, or written summary.
• Possible outcome: Sales teams can access customer order insights faster, spend less time searching through data, and make decisions more efficiently.

Healthcare industry: Auditing dashboard access with the AI Copilot

• Scenario: A healthcare analytics administrator needs to review who has access to patient outcome dashboards before a compliance audit.
• Challenge: Manually reviewing permissions across multiple analytics assets can be time-consuming.
• How AI Copilot helps: The healthcare administrators asks, “Visualize patient admissions over time.” AI Copilot uses the dashboard context to help investigate trends, identify patterns in patient volumes, and answer follow-up questions in natural language.
• Possible outcome: Healthcare administrators can find the main insights faster, uncover opportunities more efficiently, and spend less time manually reviewing dashboard.

Sales: Understanding Dashboard Dependencies with the Bold BI MCP Tool

• Scenario: A sales analyst needs to understand which dashboards use the Sales Analysis Data source before requesting updates to the underlying sales data.
• Challenge: Identifying linked dashboards, reviewing widget details, and understanding the potential impact of data source changes can require checking multiple resources manually.
• How the Bold BI MCP Tool helps: The sales analyst asks, “Show the dashboards connected to the Sales Analysis Data source.” Through an MCP-compatible AI client, the Bold BI MCP Tool retrieves the related dashboard information. The analyst can continue with follow-up requests such as viewing widget details, reviewing dependencies, or exporting dashboard information.
• Possible outcome: Sales analysts can quickly identify dashboard dependencies, assess the impact of planned data changes, and access relevant dashboard information through natural language conversations.

Retail industry: Getting instant insights with AI Agent

• Scenario: A retail operations manager wants to proactively monitor inventory levels across stores and receive alerts when popular products are running low.
• Challenge: Continuously tracking inventory, identifying stock shortages, and coordinating replenishment can require constant manual monitoring and action.
• How AI Agent helps: The manager instructs the AI Agent, “Monitor inventory levels for high-demand products and notify me when stock falls below the reorder threshold.” The AI Agent autonomously monitors the relevant data, detects low-stock situations, triggers notifications, and can even recommend replenishment actions based on predefined business rules.
• Possible outcome: Retail teams can prevent stockouts, improve inventory availability, reduce manual monitoring efforts, and ensure customers consistently find the products they need.

As AI adoption grows, governance becomes just as important as usability.

For AI Assistant, organizations can apply existing security models such as authentication controls and row-level security configurations within embedded analytics environments.

For MCP workflows, the tool runs with the permissions of the user the API key belongs to, so a least-privilege user limits what the AI app can see. Bold BI notes that audit activity is reviewable through Dashboard Usage Insights on premises, and that cloud coverage may differ.

Key governance benefits include:

• Easier access management
• Least-privilege implementation
• Controlled credential management
• Improved administrative oversight

Bold BI also supports bring-your-own-key for AI models. The AI Assistant page lists OpenAI and Azure OpenAI, and Anthropic Claude from version 16.1.90.

Limits to plan around

A few limits shape the choice:

• AI Assistant works with one data source or one dashboard at a time, and it can’t edit dashboards.
• The MCP Tool is read-only. It doesn’t replace AI Copilot for building dashboards.
• Audit coverage for MCP activity differs between on-premises and cloud, so check what you can review.

A simple evaluation plan

The most reliable way to choose an AI experience is through hands-on testing.

1. Select a business use case and data source.
2. Test common analytics questions using AI Assistant.
3. Evaluate dashboard exploration workflows with AI Agent.
4. Explore dashboard creation scenarios with AI Copilot.
5. Connect a compatible AI platform through the MCP Tool.
6. Compare user experience, governance controls, and operational capabilities.
7. Validate outputs across different permission levels.

This process helps teams identify the approach that best supports their users and workflows.

Choose the AI experience that matches the workflow

The most successful AI analytics strategies start by matching the right technology to the right audience.

Teams building dashboards can accelerate development with AI Copilot. Dashboard viewers can explore insights more efficiently with AI Agent. Organizations embedding analytics into their products can provide conversational experiences through AI Assistant. Developers and data teams working within AI platforms can extend analytics workflows using the Bold BI® MCP Tool.

Rather than asking which AI capability is best, ask which one best supports the workflow you’re trying to improve.

Ready to explore AI-powered analytics with Bold BI? Start a free 30-day trial and see how the right AI experience can help your teams create, explore, and operationalize analytics more effectively.

Frequently asked questions

1. What is the difference between AI Agent and AI Assistant?
   AI Agent lives inside the Dashboard Viewer and answers questions about the open dashboard. AI Assistant is its own workspace with saved, resumable conversations and isn’t tied to one dashboard.
2. Which AI models can I use with Bold BI?
   Bold BI supports multiple AI models and providers. For bring-your-own-key, the AI Assistant page lists OpenAI and Azure OpenAI, and Anthropic Claude from version 16.1.90.
3. Does the MCP Tool work with on-premises Bold BI?
   Bold BI’s MCP Server page says it works with Cloud and on-premises deployments with a valid API key. Check the setup guide for network requirements.
4. Do these features follow my permissions?
   In embedded sessions, Bold BI states that SSO and row-level security carry into the AI Assistant. The MCP Tool runs with the permissions of the user the API key belongs to, so use a least-privilege user.
5. When should I use the Bold BI MCP Tool instead of AI Assistant?
   Use AI Assistant when users need conversational analytics inside an application. Use the Bold BI MCP Tool when AI platforms such as Claude, ChatGPT, GitHub Copilot, or VS Code need to read, query, and export dashboards, data sources, permissions, and other analytics resources.
6. What is the difference between AI Copilot and the Bold BI MCP Tool?
   AI Copilot helps dashboard authors create and edit analytics content inside Bold BI. The Bold BI MCP Tool allows external AI applications to work with analytics resources through MCP-enabled workflows.
7. Can AI Assistant query multiple data sources at once?
   No. AI Assistant works with one dashboard or one data source at a time. Organizations should plan data models accordingly when designing conversational analytics experiences.

Originally published at https://www.boldbi.com on October 8, 2026.

Bold BI MCP Tool vs. AI Assistant, Agent and Copilot was originally published in Bold BI on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR: Data residency compliance goes beyond choosing a database region. Organizations must understand where data is stored, processed, transferred, cached, backed up, and accessed across the entire analytics ecosystem. These eight questions help evaluate embedded analytics vendors and identify potential compliance, security, and residency risks.

Introduction

When evaluating data residency compliance, the first question is usually, “Where is the database located?” However, compliance requirements extend far beyond database hosting. Data can also be copied to caches, backups, disaster recovery environments, logs, exports, AI services, and third-party integrations. Each location creates its own residency, governance, and regulatory obligations.

This guide outlines eight important questions security and compliance teams should ask when evaluating embedded analytics vendors. By following every place data is stored, processed, or transferred, organizations can better assess residency risks and choose a deployment model that aligns with their requirements.

What is data residency compliance?

Data residency compliance refers to meeting regulatory, contractual, and organizational requirements that govern where data is stored, processed, transferred, and accessed. While the terms are often used interchangeably, data residency, data sovereignty, and data localization have distinct meanings.

Why embedded analytics makes data residency harder

A standalone BI tool serves your own staff. Embedded analytics serves your customers, inside your product, often across regions. That changes the stakes in two ways.

First, your customers’ data now flows through a third party’s software. Second, each customer may have different residency terms in their contract with you.

Take a hypothetical EU fintech that embeds spending dashboards for business clients in Germany and France. Its contracts promise that client data stays in the EU.

Under the EU’s rules on international data transfers, moving personal data outside the European Economic Area requires a legal mechanism such as an adequacy decision or standard contractual clauses. So every place the analytics layer copies data matters, not just the primary database.

8 questions to ask embedded analytics vendors about data residency

Data residency risks often exist beyond the primary database. These eight questions can help uncover them before they become compliance or security issues.

Where is data stored, cached, and backed up?

Ask whether dashboards query your database live or copy data into an extract. Extracts are faster. But they’re copies, and copies have their own location. Bold BI® supports both: live mode queries the source directly, while extract mode stores optimized snapshots on the Bold BI side. Choose per data source.

Organizations should also ask about backups, disaster recovery environments, database replication, and business continuity plans. Copies created for resilience may be stored in different locations than production systems. For example, an EU fintech that stores production data in the EU would need to understand whether backups, disaster recovery replicas, or failover systems are retained elsewhere.

Good answer: A clear map of every place data is stored, including caches, with the region for each.

Where does the analytics server itself run?

Bold BI’s shared cloud runs in the US region. According to Bold BI’s hosting locations guidance, managed hosting is created in the US by default, but Bold BI can deploy it in another region on request, and costs may vary by region. For EU-only data, that means managed private cloud in an EU region or the on-premises edition. Organizations that need fully air-gapped networks should use the on-premises edition.

Good answer: A named region and a documented option to run in your region or your own environment with the same features.

Where do AI features send data?

AI assistants send prompts, and often data samples or query results, to a language model. Ask which model provider is used, in which region, whether prompts are kept, and whether AI can be switched off per tenant. Bold BI supports bring your own key (BYOK) capabilities, helping organizations maintain greater control over AI-related data flows. The AI provider, processing region and retention policy depend on the model and BYOK configuration you choose.

Good answer: The provider, the region, the retention policy, and clear administrative controls over AI usage.

How are tenants kept apart?

Residency is meaningless if one tenant can see another’s data. Ask how isolation is enforced (row-level rules, separate databases or both) and how it’s tested. In Bold BI, row-level security for embedded dashboards is applied on the server through the embed token. Bold BI supports site-per-tenant setups, and custom attributes can switch the data connection for each tenant when databases share a schema.

Good answer: Server-side enforcement, support for separate databases per tenant, and a repeatable cross-tenant test.

Where do logs, exports, and scheduled emails go?

Audit logs, error logs, PDF exports and scheduled email reports all contain data. Ask where each is stored, how long it’s kept, and who can access it. A dashboard can stay in the EU while its monthly PDF report travels anywhere an email can go. Bold BI includes an audit trail for tracking user activity.

Good answer: Documented locations and retention policies for every log and export type, along with admin controls over scheduling.

Which integrations and support teams sit outside the deployment?

Bold BI’s MCP Server is a hosted service that connects AI clients to Bold BI through APIs. It needs outbound HTTPS, so it won’t work inside a fully air-gapped network. It acts with the permissions of the API key you give it, so use a least-privilege account.

Organizations should also ask about vendor support access and subprocessors. Bold BI maintains a published subprocessor list that identifies the third-party services used to deliver the platform and where those providers operate.

Good answer: A list of every hosted component, the data it touches, and whether it can be disabled.

What independent evidence can you see?

Certifications don’t prove residency. They do show that controls are audited.

Bold BI completes an annual SOC 2 Type 2 audit covering a 12-month period, and customers and prospects can request the report through support or sales. On Bold BI’s hosted platform, data is encrypted with TLS 1.2 in transit and AES-256 at rest.

Also review the vendor’s Data Processing Addendum (DPA). Bold BI’s DPA includes EU data transfer clauses and requires 30 days’ notice before sub-processors are added or replaced. Self-hosted Bold BI Embedded is outside its scope, because the software runs on your own systems.

Good answer: A current report you can review under NDA, not just a badge on a web page.

Can we move the whole stack if our rules change?

Residency rules change. So do customer contracts. The safest vendor is one where moving from cloud to private cloud, or on-premises, is a change of hosting, not a migration project. Bold BI provides cloud, managed private cloud, and on-premises deployment options designed to support a consistent analytics experience across environments.

Good answer: The same features across every hosting option and a documented path between them.

Data residency checklist: how Bold BI answers each question

Use this checklist in vendor evaluations. The last column shows Bold BI’s answer for each question.

Conclusion

By asking these eight questions during vendor evaluations, security and compliance teams can identify data residency risks before contracts are signed. A practical approach is to create a complete data-flow map that traces where customer data is stored, processed, transferred, backed up, logged, exported, and accessed. This often reveals compliance gaps that aren’t visible when evaluating database location alone.

Ready to evaluate embedded analytics platforms against your data residency requirements? Start a free trial to explore Bold BI’s embedded analytics capabilities firsthand, or schedule a personalized demo to discuss your data residency, security, and deployment requirements with our team.

Frequently asked questions

1. Is data residency the same as GDPR compliance?

No. Residency is about where data is stored and processed. GDPR covers much more, including lawful basis, rights and security. Keeping data in the EU can simplify transfers, but it doesn’t make a system compliant on its own. Legal and compliance teams should confirm which regulations, such as GDPR, UK GDPR or HIPAA, apply.

2. Does self-hosting solve data residency?

It solves where the core system runs. You still need to check AI providers, hosted add-ons, email delivery and backups, because each can move data elsewhere.

3. Can one embedded analytics platform serve EU and US customers?

Yes, if it can run in more than one environment. Many SaaS teams run a separate deployment per region and route each tenant to the right one.

4. What should we ask for in writing?

The data flow map, the list of subprocessors and regions, the AI data policy and the audit report. The EDPB’s guide on international transfers explains what a transfer impact assessment should cover.

Originally published at https://www.boldbi.com on October 5, 2026.

Data Residency Compliance for Embedded Analytics | Bold BI was originally published in Bold BI on Medium, where people are continuing the conversation by highlighting and responding to this story.