BI Data Isolation and Permission Governance in Multi-Tenant SaaS Architecture

Introduction

When SaaS vendors integrate embedded BI, the first three questions customers always ask are: Will my data be visible to other tenants? Can different tenants have different metric definitions? Can the permission system integrate with my existing role system?

The essence of these three questions is the same proposition: data isolation and permission governance in a multi-tenant architecture. This is not a feature that can be “filled in after launch” — if multi-tenant isolation is not handled properly during the architecture design phase, the subsequent data leakage risks and operational costs will be catastrophic.

In the process of serving 200+ ISV partners, HENGSHI SENSE has built a mature multi-tenant BI architecture system. This article provides an in-depth analysis of the multi-tenant technical implementation of BI platforms in SaaS scenarios from three dimensions: data isolation, permission governance, and tenant management.

---

1. Three-Layer Mechanism for Multi-Tenant Data Isolation

1.1 Core Principles of Data Isolation

The design of multi-tenant data isolation follows three core principles:

• Logical Isolation: Data from different tenants is completely independent at the logical level — datasets, metric definitions, and dashboard configurations are all tenant-private
• Clear Permission Boundaries: The data access scope of each tenant is controlled by its tenant administrator and is not subject to platform administrator intervention
• Unaffected Performance: Data isolation between tenants does not come at the expense of query performance — when 100+ tenants query concurrently, each tenant’s response time is not affected by other tenants

1.2 Dataset-Level Isolation

Each tenant has an independent dataset configuration space:

Data Connection Isolation

Tenant administrators create and manage their own data connections within the tenant space — authentication credentials, connection parameters, and network configurations are all tenant-private and inaccessible to other tenants.

For SaaS vendors with self-built data warehouses, the data connection isolation mechanism ensures that each tenant can only connect to its own database schema or data partition.

Dataset Definition Isolation

Dataset definitions are independently managed for each tenant — datasets representing the same business concept may have different field mappings, data types, and calculation logic across different tenants. For example, the “Customer Table” might contain 10 fields in Tenant A and 15 fields in Tenant B, with no interference between them.

Data Model Isolation

The association relationships between datasets (Join/Union) are also tenant-private. The same set of datasets can establish different association models across different tenants — Tenant A might need a “Customer Table Join Order Table” model, while Tenant B might need a more complex “Customer Table Join Order Table Join Product Table” model.

1.3 Metric Definition Isolation

Metric definition isolation is the core characteristic of the multi-tenant BI architecture — the same business concept can have different calculation logic across different tenants:

Atomic Metric Isolation

Atomic metric definitions are independently managed for each tenant. For example, “Sales Amount” might be defined as SUM(order_net_price) (net sales) in Tenant A, while Tenant B defines it as SUM(order_gross_price) (gross sales) — the two tenants have completely different calculation logic for “Sales Amount,” but both are correct within their own business contexts.

Business Metric Isolation

Dimension conditions, granularity declarations, and KPI targets for business metrics are all tenant-private. Tenant A’s “East China Monthly Sales” and Tenant B’s “East China Monthly Sales” can reference different atomic metrics, use different dimension value mappings, and employ different granularity definitions.

Semantic Annotation Isolation

Semantic annotations for each tenant’s metrics are independently maintained — aliases, business descriptions, and usage scenario annotations are all tenant-private. This means the same metric can have different natural language aliases across different tenants, and ChatBI semantic matching results are tenant-specific.

1.4 Dashboard Configuration Isolation

Dashboard Isolation

Each tenant’s dashboard configurations are independently managed — layout, chart types, filters, and parameters are all tenant-private. ISVs can provide different dashboard templates for different tenants, and tenant administrators can make personalized adjustments based on templates.

Publishing Permission Isolation

Dashboard publishing and sharing permissions are independently configured by tenant administrators — different tenants can have completely different publishing strategies. Some tenants may allow all users to publish dashboards, while others may restrict publishing to administrators only.

---

2. Permission Governance System

2.1 Three-Tier Permission Model

HENGSHI SENSE’s multi-tenant permission system adopts a three-tier model:

Tier 1: Platform-Level Permissions

Platform administrators (typically the ISV’s operations team) manage the overall platform configuration:

• Creating, suspending, and deleting tenants
• Allocating global resource quotas (computing resources, storage space)
• Configuring platform-level security policies (SSO protocols, encryption strategies)

Tier 2: Tenant-Level Permissions

Tenant administrators manage all configurations within their tenant:

• Creating users, assigning roles, and configuring permissions
• Data connection, dataset, metric, and dashboard management permissions
• Configuring publishing permissions and sharing strategies

Tier 3: User-Level Permissions

End users have operational permissions within their permission scope:

• Data access permissions: which datasets and metrics they can view
• Data operation permissions: which operations they can perform (view, edit, publish, share)
• Dimension access permissions: which dimension data they can view (e.g., regional managers can only view data for their region)

2.2 Field-Level Permission Control

Field-level permissions are the fine-grained tool for multi-tenant BI permission governance — they control which fields in a dataset a user can access:

Scenario Example

In a CRM SaaS scenario, the “Customer Table” includes fields such as customer name, contact information, and credit rating. Field access permissions may differ for different roles:

• Sales representatives: can view customer names and contact information, but cannot view credit ratings
• Regional managers: can view customer names, contact information, and credit ratings
• Finance personnel: can view all fields

Technical Implementation

Field-level permissions are defined in the semantic layer — each field is associated with a “visible role list.” During reasoning, the Agent can only access fields within the current user’s role permission scope; fields outside the permission scope will not appear in the query’s SELECT list.

This mechanism ensures that even if the Agent generates a query request containing all fields, the permission layer automatically filters out fields beyond the user’s permission before execution.

2.3 Row-Level Dynamic Filtering

Row-level filtering controls which data rows in a dataset a user can access — this is the core mechanism of multi-tenant BI permission governance:

Scenario Example

In a retail SaaS scenario, the “Order Table” contains order data for all stores. Row-level access permissions may differ for different roles:

• Store managers: can only view order data for their own store
• Regional managers: can only view order data for all stores in their region
• Headquarters management: can view order data for all stores

Technical Implementation

Row-level filtering is automatically injected during query generation — before the SQL query generated by the Agent is executed, the permission layer automatically appends WHERE conditions. Filtering conditions are dynamically calculated based on the user’s role and business attributes:

-- Query for store manager automatically appends:
WHERE store_id = ${user.store_id}

-- Query for regional manager automatically appends:
WHERE region_id = ${user.region_id}

-- Query for headquarters management has no filtering condition appended

The key design of row-level filtering is “dynamic calculation” — filtering conditions are not hardcoded rules but are calculated in real-time based on user context. When a user’s role or business attributes change, filtering conditions automatically update without requiring manual permission configuration changes.

2.4 SSO and Permission Mapping

In a multi-tenant SaaS scenario, the BI platform’s identity authentication needs to seamlessly integrate with the ISV business system’s identity system:

SSO Single Sign-On

Supports mainstream SSO protocols such as OAuth 2.0 and SAML 2.0. When users log into the ISV business system, they do not need to log in again when accessing BI features — SSO protocols automatically complete identity authentication and session establishment.

Role Mapping

The role system of the ISV business system is synchronized to the BI platform through mapping rules:

ISV Role	BI Platform Role	Data Access Scope
System Administrator	Tenant Administrator	Full tenant data
Department Manager	Data Analyst	Department data
Frontline Employee	Data Viewer	Personal data

Role mapping supports dynamic updates — when the role configuration in the ISV business system changes, the BI platform’s role mapping automatically synchronizes without requiring manual maintenance of two separate permission systems.

---

3. Tenant Management Operations System

3.1 Tenant Lifecycle Management

Tenant Creation

ISVs create new tenants through APIs or the management interface, configuring tenant basic parameters:

• Tenant name and identifier
• Data connection configuration (or using ISV preset data connection templates)
• Resource quotas (concurrent query limits, storage space limits)
• Permission policy templates

After tenant creation, the system automatically initializes the tenant’s data space — dataset templates, metric templates, and dashboard templates are automatically loaded, allowing tenant administrators to quickly configure their tenant’s analytics environment based on templates.

Tenant Suspension and Recovery

When a SaaS customer’s subscription expires or is suspended, the ISV can suspend the BI access permissions for the corresponding tenant — the tenant’s data and configurations are retained, but users cannot access BI features. When the customer renews, access permissions are restored, and data and configurations are fully recovered.

Tenant Deletion

When a customer formally terminates the contract, the ISV can delete the corresponding tenant — all tenant data, configurations, and audit logs are permanently erased. The system generates a data backup for the ISV to archive before the deletion operation.

3.2 Resource Quota Management

The core operational challenge of a multi-tenant BI platform is resource management — when 200+ tenants share the same platform, how to ensure fair resource allocation:

Computing Resource Quotas

Each tenant can have independently configured computing resource quotas:

• Query concurrency: maximum number of concurrently executed query requests
• Query time limit: maximum execution time for a single query
• Memory usage limit: maximum memory available during query execution

The purpose of computing resource quotas is to prevent high-frequency queries from a single tenant from affecting the response times of other tenants. When a tenant’s query requests exceed the quota, the system automatically queues or rejects them, ensuring other tenants’ queries are unaffected.

Storage Resource Quotas

Each tenant’s data storage space can have configurable upper limits:

• Dataset storage space: upper limit for dataset definitions and materialized data size
• Audit log storage space: retention time and size limit for operational audit logs
• Dashboard storage space: upper limit for dashboard configurations and cached data size

3.3 Tenant-Level Performance Monitoring

The system provides tenant-level performance monitoring dashboards, allowing ISV operations teams to view in real-time:

• Query QPS (queries per second) for each tenant
• Average query response time for each tenant
• Resource utilization (computing, storage) for each tenant
• Query failure rate and failure reasons for each tenant

Based on monitoring data, ISVs can promptly discover performance bottlenecks — for example, if a tenant’s query response time remains consistently high, it may be necessary to expand that tenant’s resource quotas or optimize their data model.

---

4. Security Compliance for Multi-Tenant Architecture

4.1 Data Encryption

Transmission Encryption

All data transmission uses TLS 1.2+ encryption to ensure data is not stolen during network transmission. Tenant data connection authentication information is also encrypted during transmission.

Storage Encryption

Sensitive tenant data (such as data connection passwords and API keys) uses AES-256 encryption during storage. Even if the database is directly accessed, attackers cannot obtain plaintext credentials.

4.2 Audit Compliance

Each tenant’s operational audit logs are independently stored, containing:

• User operation logs: complete records of each query, analysis, and publishing operation
• Management operation logs: records of each permission change and configuration modification
• Data access logs: detailed records of each data read and write operation

Audit logs support multi-dimensional retrieval by time, user, and operation type, meeting compliance review requirements for heavily regulated industries such as finance and healthcare.

4.3 Data Sovereignty Guarantee

For customers with data localization requirements (such as government and military industries), HENGSHI SENSE supports private deployment — each tenant’s data is completely stored on the customer’s own servers without any cloud transit. This deployment model ensures physical data isolation and sovereignty guarantee.

---

5. Typical Multi-Tenant Architecture Scenarios

5.1 Multi-Tenant BI for CRM SaaS

Scenario Description: CRM SaaS vendors provide independent CRM instances for each enterprise customer, each requiring embedded data analytics functionality.

HENGSHI Solution:

• Each enterprise customer corresponds to one BI tenant
• The tenant’s data connection points to that customer’s CRM database schema
• ISV presets standard dashboard templates and metric templates, automatically loaded when new tenants are created
• Tenant administrators can make personalized adjustments based on templates

Implementation Results: The cycle for new customers to access BI functionality decreased from 2 weeks to 2 days — tenant creation, template loading, and data connection configuration are completed within 1 day, and standard analytics features can be launched on the second day.

5.2 Multi-Level BI for Retail Chains

Scenario Description: Retail chain enterprises have a three-tier management structure of headquarters-region-store, with different levels of users requiring different granularities of data analytics.

HENGSHI Solution:

• Three-tier permission model within a single tenant: headquarters management (full data), regional managers (regional data), store managers (store-level data)
• Row-level dynamic filtering: automatically filtering data scope based on user’s organizational hierarchy
• Tiered dashboard configuration: headquarters dashboard (national summary), regional dashboard (regional comparison), store dashboard (single-store operations)

Implementation Results: Data permissions under the three-tier management structure are completely automated — users do not need to manually select data scope; the system automatically filters based on user roles.

---

6. Implementation Recommendations for Multi-Tenant Architecture

6.1 Isolation Strategy Selection

Isolation Strategy	Data Isolation Level	Operational Complexity	Applicable Scenarios
Independent Deployment	Highest (Physical Isolation)	High (Independent deployment per tenant)	Heavily regulated industries, large customers
Shared Engine + Independent Schema	High (Logical Isolation)	Medium	Medium-sized SaaS customers
Shared Engine + Shared Schema + Row-Level Filtering	Medium (Row-Level Isolation)	Low	Small SaaS customers

It is recommended that SaaS vendors select appropriate isolation strategies based on customer scale and industry requirements — not pursuing “maximum isolation” but rather “sufficient and controllable.”

6.2 Prior Design of Permission System

Complete the design and testing of the permission system before BI functionality goes live:

• Sort out the ISV business system’s role system and design role mapping rules
• Configure row-level filtering rules for core scenarios and verify filtering effects
• Test the coverage of field-level permissions to ensure effective access control for sensitive fields

Prior design of the permission system can avoid the passive situation of “discovering permission loopholes after launch” — in multi-tenant scenarios, the impact scope of permission loopholes affects the entire tenant, and remediation costs are much higher than upfront design.

6.3 Synchronous Construction of Monitoring System

The monitoring system for a multi-tenant BI platform should go live simultaneously with the features, with key monitoring areas:

• Data isolation effectiveness between tenants — whether there are anomalies indicating cross-tenant data leakage
• Tenant-level performance indicators — whether there are performance degradation issues for any tenant
• Balance of resource utilization — whether any tenant’s resource utilization is too high, affecting other tenants

---

Conclusion

The core challenge of multi-tenant BI architecture is not technical implementation, but the design of security boundaries — finding the balance between “flexible sharing” and “strict isolation.”

HENGSHI’s three-layer data isolation mechanism, three-tier permission model, and tenant-level resource management system provide SaaS vendors with a mature multi-tenant BI architecture solution. The core design philosophy of this solution is: let ISVs focus on business logic, and let HENGSHI handle the technical foundation — ISVs do not need to invest large amounts of R&D resources to build their own multi-tenant BI infrastructure. They only need to configure APIs and design templates to provide each tenant with independent, secure, and high-performance data analytics experience.

When a SaaS customer asks “Will my data be visible to other tenants?”, the answer should not be a vague “no,” but rather a complete set of isolation mechanisms — from data connections to datasets, from metric definitions to dashboard configurations, from field-level permissions to row-level filtering, every layer has clear isolation rules and technical guarantees. This is how multi-tenant BI architecture truly earns customer trust.