Article body
Full article
SaaS vendors serving multiple enterprise customers often encounter two kinds of analytics needs. Some customers want standard business reports; others need to connect their own data, adjust metrics, and build dashboards. The platform must keep improving shared analytics capabilities while giving each tenant an independent workspace and governance permissions.
HENGSHI’s multitenant BI PaaS brings tenant spaces, data connections, data packages, analytics applications, identity and permissions, and engine resources into one delivery system. Platforms can provide data and analytics at different levels, while tenants continue modeling, creating, and distributing content within their authorization. This allows SaaS vendors to offer both standard analytics products and self-service analytics for selected customers.
From platform delivery to tenant self-service: start with resource relationships
The diagram shows the basic relationship between shared platform resources and tenant-local resources. Understanding its technical value requires tracing three questions: how user identity maps to data scope, which resource layer the platform delivers, and who maintains new resources created by a tenant.
1. Tenant spaces: align customer organizations with analytics asset management
HENGSHI provides an independent analytics space for each tenant. Tenant administrators manage users and authorization within their spaces. Members can use modules such as data connections, the data marketplace, application creation, and the application marketplace to model data, analyze it, and deliver content according to their roles. The platform manages tenants; tenant administrators manage usage within their own enterprises.
This structure maps a SaaS vendor’s enterprise customers to tenants in its analytics service. A business dashboard created by customer A and business data connected by customer B are maintained in their respective spaces. When the platform delivers shared resources, resource ownership and subsequent authorization remain distinct, keeping platform operations separate from customers’ internal management responsibilities.
- Platform operator: Maintains shared data and analytics products and decides which resources to deliver to which tenants.
- Tenant administrator: Organizes members, allocates resources, and maintains internal permissions within the tenant space.
- Tenant member: Views data, models data, or creates applications according to granted feature and data permissions.
Reference: Tenant management.
2. Identity and user attributes: bring customer context into data access
When a user enters embedded analytics, the business system usually already knows their enterprise, department, store, and role. HENGSHI can use SSO, JWT, or user attribute synchronization to apply this identity information to subsequent resource authorization and data filtering. Integration teams should map business customers, HENGSHI tenants, users, and user attributes before loading the analytics page.
| Mapping object | Information carried | Purpose in multitenant analytics |
|---|---|---|
| Enterprise / tenant | Enterprise identifier, name, and platform relationship | Determine which tenant space the user enters |
| User / role | Login identity and authorized functional roles | Determine whether the user can view, analyze, or manage resources |
| User attributes | Business context such as regions, organizations, and sets of stores | Provide inputs for data filtering, dynamic connections, or analysis context |
HENGSHI supports multiple authentication methods at the same time. Enterprises with a standard identity provider can use LDAP, CAS, SAML2, OAuth2, and other supported methods. A host system that has already authenticated a user can pass the current identity into a page or SDK through a JWT request parameter. JWT claim mappings can also populate user fields or attributes.
After enterprise information mappings are configured, tenant authentication mode can generate the relevant tenant record on first login. The platform can also create tenants manually. These options let the platform align integration with its own onboarding and identity processes. JWT carries identity; organization synchronization, account deactivation, and coordinated logout still need to be specified in the integration design.
References: Authentication and JWT, Data permission solutions.
3. Data isolation: support shared tables, separate databases, and tenant-owned data
Tenant data in a SaaS service may use different storage structures. HENGSHI adapts through connections, user attributes, and permission rules, while analytics continues to use business objects such as datasets, metrics, and applications. Identify where data is actually stored before selecting the access path.
| Data organization | HENGSHI approach | Design focus |
|---|---|---|
| Shared database and shared tables | Apply tenant or organization attributes to data filtering rules on connections or applications | Align tenant identifiers, user attributes, and permission conditions |
| Separate instances, databases, or schemas | Use user attributes in supported connection properties and data references for dynamic access | Check source drivers, attribute mappings, and actual access targets |
| Platform data plus tenant-private data | Distribute shared data packages; tenants connect and relate their own data within their spaces | Define join keys, metric definitions, ownership, and permissions for new objects |
User attributes can define data scope and support dynamic connections
For example, a platform can maintain mappings for enterprise affiliation, database addresses, or database names, allowing the same type of analysis logic to access the corresponding data environment through user attributes. HENGSHI connection management permits user attributes in supported connection property fields. Expressions in applications or datasets can also use attributes for business filtering.
Attribute scope distinguishes “internal” from “global.” A platform can set global attribute values per tenant so that members of that tenant receive the appropriate values; internal attributes apply within the space. Attribute exposure can also be read-only or hidden. Hidden attributes are mainly used for connections to avoid directly displaying relevant configuration values to ordinary users. The visibility of an attribute definition and the scope of its values are separate concepts.
These mechanisms support reuse of models and connection configurations without requiring every customer to use the same database architecture. For customers with substantially different storage structures, the platform can connect sources separately and reuse compatible metrics and application structures above them.
References: Connection management, User attributes.
4. Layered distribution: what the platform delivers determines where self-service begins
HENGSHI supports delivery to tenants at the connection, data package, and application layers. A platform can expand access according to customer maturity: start with standard dashboards, provide data packages for further analysis, then offer more complete modeling conditions to customers with suitable data capabilities.
| Delivered object | Tenant’s analytical starting point | Suitable need |
|---|---|---|
| Data connection | Use the connection within authorized catalogs, tables, and data scope | Tenants need to organize and process data themselves |
| Data package | Use datasets and analytical models prepared by the platform | The platform standardizes business objects while tenants analyze and extend them |
| Applications in team / public spaces | View, copy where permitted, or export templates | Distribute standard reports and support personalized creation from examples |
Connection authorization is itself layered. HENGSHI distinguishes listing names (LS), viewing schemas (SC), read-only access (RO), and full access (RW), with rules at connection, catalog, and table levels. Table-level RO rules support row and column controls; complex cross-table filtering can also use SQL expressions. The platform can therefore grant capabilities appropriate to an analysis task instead of exposing every operation on a data source to every customer.
The default delivery chain is platform-to-tenant authorization followed by tenant-administrator authorization to members. Platform-shared data packages and applications appear in corresponding platform-resource locations in the tenant interface, distinguishing supplied content from local creations. Sharing is based on one-way distribution from platform to tenant; tenant-local content does not automatically flow back to the platform.
References: Connection permissions, Multitenancy and OEM.
5. Data permission modes: serve different users through the same report
Resource authorization determines whether someone can enter an application. Data permissions determine whose data identity and which rules its charts use for computation. HENGSHI applications provide application-author, dataset-author, and user data permission modes, which should be part of delivery design during evaluation and implementation.
| Data permission mode | Data identity used for computation | Design approach |
|---|---|---|
| Application author | Data accessible to the application creator, with applicable application rules | The platform prepares standard analysis and controls its distribution |
| Dataset author | Data accessible to the dataset creator, with applicable application rules | Reuse prepared data assets for report delivery |
| User | The current user’s connection access permissions | Query according to the visitor’s own connection rules |
User mode accesses data through the current account’s connection permissions; application-level row permission settings cannot simply be carried over to that mode. Applications containing datasets in the import engine also cannot be directly switched to user mode. The mode affects query identity and engine usage conditions, so it should be determined when designing standard reports.
Continue checking permission sources when creating analytical objects. Row permissions on a base dataset do not automatically propagate to a newly created join dataset. If a tenant or platform creates a dataset through joins, confirm rules on the new object and test with the intended user. Inherited connection rules and new rules may also apply together; inspect the final authorized scope.
For customers organized by store, first use enterprise affiliation to limit tenant data, then use each user’s authorized store set to configure visibility, with column permissions for sensitive fields. Operational permissions such as viewing details and exporting data should be configured and verified separately. Frontend filters support interactive selection; actual access scope is determined by server-side identity and permission configuration.
References: Application settings and data permission modes, Row and column permission controls.
6. Standard products and personalized analysis: combine shared models with tenant creation
When maintaining shared models, a platform can organize common industry business objects, metrics, and dashboards into standard analytics products. After inheriting or using authorized data packages, tenants can analyze within their own spaces and relate their own data as needed. For example, a cross-border ecommerce customer can combine platform order data with its own cost data to build company-specific profit analysis.
Tenants cannot directly modify the original content of platform-shared resources. Where personalization is needed, permitted copy or template mechanisms can create independent resources maintained by the tenant. This protects shared analytics products while accommodating customer-specific fields, metric definitions, and dashboard layouts.
| Reuse goal | Suitable method | Handling updates |
|---|---|---|
| Multiple people edit one application | Application collaboration | Maintain the same object according to collaboration roles and publication permissions |
| A customer needs an independently adjustable dashboard | Create a copy | Assign independent maintenance responsibility and check changes separately |
| Reuse an analytics structure across environments | Export a template / create from a template | Check connections, data package dependencies, and target data structures |
A published application delivers the content present at publication time; changes in the creation area require republication. With the appropriate authorization and application version management enabled for the tenant, tenants can also preview and restore historical analysis versions. These versions include analytical content such as dashboards, datasets, models, and parameters, but exclude data connections and permission settings. Current connections and authorization still need verification after restoration.
Updates to standard dashboards and evolution of tenant copies should be maintained separately. Platforms can announce new metrics and layout changes for tenants to assess. When using templates across environments, check data package bindings rather than assuming that changing a database address adapts every reference.
References: Application delivery and templates, Application version management.
7. Tenant operations: from onboarding and authorization to resource allocation
Multitenant delivery also involves service periods and computing resources. HENGSHI tenant management maintains tenant status, validity periods, user quotas, and expiry reminders, and supports license updates and enabling or disabling tenants. Platforms can allocate engine resources for individual tenants, with resource shares corresponding to CPU capacity and memory.
Platforms can manage customer onboarding alongside analytics resource planning: confirm service scope during onboarding, allocate engine shares according to need, observe load after launch, and adjust resources and analytical methods. Engine allocation concerns HENGSHI engine resources. Source database compute, model-service quotas, and external system capacity need separate planning based on actual invocation paths.
- Onboarding: Check multitenancy licensing, enterprise mappings, service validity, and member count.
- Delivery: Define the connection, data package, or application authorization list and the tenant’s subsequent member authorization process.
- Operations: Check query durations, refresh tasks, and usage peaks; assess data-engine and source-system capacity using evidence.
- Deactivation: Address login and access, shared resources, and retained tenant data, recording delivery disposition.
Reference: Tenant licensing and engine allocation.
8. Published examples: standard report distribution and tenant self-service
Fenbeitong: delivering shared analytical content to enterprise customers
HENGSHI’s BI PaaS Scenario-Based Analytics White Paper describes how Fenbeitong connects tenant information through SSO and user attributes, combines common reports with permission rules so different tenants see their own data, and embeds analytics in its expense management product. This illustrates how a platform can maintain common business content and distribute it according to identity.
Lingxing: enabling personalized analysis on top of shared data
The same white paper records that Lingxing provides platform-built reports to tenants while also opening self-service analytics to selected customers. Tenants can use distributed data packages and connect their own databases for further analysis. This illustrates an expansion from consuming standard reports to customer-led modeling.
Case source: HENGSHI BI PaaS Scenario-Based Analytics White Paper, pages 20–24.
9. Connecting Agentic BI to the existing tenant resource system
Multitenant BI PaaS provides manageable business resources for intelligent analysis. After entering a tenant space, users can ask natural-language questions and continue analysis around existing datasets, metrics, and dashboards through enabled Data Agent entry points. Supported creation entry points can further generate or adjust visual content.
For example, when a regional manager at customer A asks to “compare this month’s refund rates across stores,” analysis needs to use A’s metric definitions, authorized stores, and data connections. Any resulting dashboard is then delivered to colleagues according to the tenant’s internal rules. The platform shares general analytical methods while tenants retain local data and created results, bringing intelligent analysis into existing governance processes.
If a SaaS vendor adds knowledge retrieval, conversation caches, or business-action tools, those components should validate the relevant tenant and caller identity. The scope of system prompts, model configuration, and tenant entry-point switches should be confirmed separately. Integrations need to connect the existing multitenant resource mechanisms with the implementation responsibilities of external components; a prompt declaring a customer identity is insufficient.
Reference: Data Agent and ChatBI.
Validate multitenancy through the actual delivery chain
| Validation scenario | Expected result |
|---|---|
| Enterprise identity mapping | Users enter the correct tenant; organization and store attributes match the host system |
| Different data storage structures | Shared-table filters, dynamic connections, or private-data access produce the intended scope |
| Layered platform authorization | Authorization relationships across connections, data packages, applications, and tenant members are clear |
| Tenant self-service processing | Derived datasets, metrics, and new dashboards have verifiable data and permission sources |
| Versions and personalized changes | Platform publications, tenant copies, and historical versions update according to their respective maintenance methods |
| Peak usage and renewal operations | Operations are verified against resource shares, query paths, and service licensing |
HENGSHI multitenant BI PaaS derives its value from these mechanisms working together. Platforms can keep distributing shared analytics products to customers, while customers extend their own data and analytics in independent spaces. For SaaS vendors, this provides a path from fixed reports and personalized delivery toward self-service analytics and Agentic BI.