Article body
Full article
When a group company or SaaS platform provides analytical capability to multiple enterprise customers, it must answer two questions: can different tenants analyze data in their own spaces, and who can see data the platform shares? HENGSHI’s multi-tenant capability addresses this boundary through tenant spaces, resource sharing, and permission configuration. The security outcome depends on the specific authorizations and validation, not merely on whether multi-tenancy is enabled.
1. Define Platform and Tenant Responsibilities First
HENGSHI product documentation describes multi-tenancy as a model in which one platform provider serves multiple enterprise customers. The capability requires the appropriate authorization. The platform provider creates and manages tenants, while tenant administrators maintain users and analytical spaces in their own tenant. Tenant spaces are independent. The platform provider can share connections, data packages, and applications with tenants, and sharing flows from the platform to the tenant.
Authorizing a data package or application to a tenant does not mean all ordinary users within that tenant can immediately see it. The tenant administrator must still grant secondary authorization according to roles and business needs. During delivery planning, list the resources that platform administrators, tenant administrators, tenant analysts, and read-only users each need to access before configuring sharing and permissions. This creates a more actionable plan than a general statement about tenant isolation.
For example, a platform may provide sales analysis to different suppliers. It first identifies the tenant that contains each supplier, shares the required data packages and applications with each tenant, and configures the corresponding data scope. Each supplier’s tenant administrator then decides what procurement, sales, or management staff can see. The platform provider should not use the rationale of unified operations to manage a tenant administrator’s internal users directly. A tenant’s own analytical results also do not automatically flow back because the platform shared resources.
The space that contains a resource also affects whether it can be shared. The product documentation distinguishes team, public, and personal spaces. An application created by an individual cannot necessarily be shared directly with a tenant. Before implementation, confirm that the resource is in a shareable location, then check the resources the tenant receives and the subsequent authorization.
2. Multiple Permission Layers Determine the Data Boundary
To determine whether a user can see data, check identity and tenant membership, data-connection permissions, application-resource permissions, the application’s data-permission mode, and dataset row and column permissions together. An application can use its author, the dataset author, or the user as the identity used to access data. Where applicable, administrators can also set row and column permissions for a dataset. Row permissions limit the range of records; column permissions limit visible fields.
Table 1. Layered checks for multi-tenant analytics
| Control surface | Configuration or management object | Acceptance question |
|---|---|---|
| Tenant space | Platform provider and tenant administrator | Does the user enter the correct tenant? |
| Resource sharing | Connections, data packages, applications | After platform authorization, who still needs secondary authorization? |
| Application and data permissions | Access roles, data-permission mode | Can the user see the application, and whose data does it use? |
| Row and column permissions | Dataset rules | Are record and field scope correct? |
| Derived and public entry points | Downstream datasets, public links | Does identity-based filtering still have a basis? |
Row and column permissions need to be specific to the dataset and user. For example, two regional managers may share one sales application. Row rules can limit each person to the relevant region, while column rules hide cost fields that should not be shown. The documentation explains that multiple row rules for the same user on the same dataset take a union. When row and column permissions both apply, they take an intersection. Preview the results through actual accounts during configuration so multiple rules are not mistakenly assumed to take the strictest intersection automatically.
Permission sources also require review. Users may gain access through an individual authorization, user group, organizational structure, or system role. If a user can still see an application after one authorization is removed, the permission may not have failed; another authorization path may still apply. Administrators can query resource authorizations and their sources by user or tenant in permission management.
These rules have clear boundaries. The product documentation states that row permissions on a dataset do not automatically pass to a downstream dataset created through a join. If the downstream dataset also needs restricted access, check and configure it separately. User mode relies on the identity of the current logged-in user, so an application that needs this identity-based filtering cannot simply become a public link. Permission design needs to validate every actual access path, including application viewing, derived datasets, and exports.
An easily missed question is whether a copy or derived dataset remains secure. Row rules on datasets A and B do not automatically become rules for a joined dataset C; assess C as a new access surface. A public link also cannot simply reuse validation from a logged-in session. Once visitors no longer need to sign in, a mode that relies on user identity for filtering no longer has its prerequisite. Include these paths in the permission review before go-live.
3. Authentication Integration Does Not Replace Resource Authorization
An enterprise can choose a login and authentication method that fits its existing identity system. A successful login only proves that the identity has been recognized; it does not grant access to connections, applications, or data packages. For embedded analytics, in particular, verify the mapping among the external user, the HENGSHI user, and the tenant, as well as which tenant space the user enters after login. Follow the documentation for the target version and the implementation plan for specific protocols and configuration. Do not treat one customer’s SSO configuration as the default architecture for every environment.
4. Test the Configuration With Unauthorized-Access Scenarios
For acceptance, prepare test accounts for the platform provider, two tenants, and different roles within each tenant. Check the scope visible after the platform shares resources with a tenant, the tenant administrator’s secondary authorization, row and column filtering on the same dataset, derived datasets, public links, and export results. Record the specific resources that each test account should and should not see. When results differ, investigate permission sources and the data-permission mode.
Use the same sales data to build the test matrix. A platform administrator should see the configured scope. Tenant A users should see only the data authorized for A, and tenant B users should see only B’s data. Different roles in the same tenant should then verify access to cost columns, detail rows, and exports. Check exported files and derived datasets in addition to page screenshots, because dashboard views alone do not cover every access path.
Writing access-violation checks as reusable acceptance cases makes them easier to repeat than simply recording that a page appears normal. The following format illustrates a test record; it is not a HENGSHI permission configuration file.
case: Tenant A read-only user accesses sales analysis
identity: Tenant A / read-only user
resource: Sales application
expected_visible: Data authorized for Tenant A
expected_hidden: Tenant B data and fields limited by column permissions
paths: Page, export, derived datasetWhen there is concern about unauthorized access, first fix the reproduction conditions: account, tenant, application, dataset, data-permission mode, row and column rules, and access method. Then check the permission sources and actual query results. If necessary, pause the disputed share or public entry point, revise the configuration, and retest. Treating both inability to see and seeing data that should be hidden as repeatable cases keeps permission boundaries clear as the business expands.
Scenario: Cross-School Course Analytics for an Education SaaS Platform
An education SaaS platform provides the same course-operations dashboard to School A and School B. The platform provider shares the application and required data packages with the two tenants separately. Each school’s tenant administrator then authorizes academic-affairs and management staff. After the platform completes sharing, it still needs to check the tenant each user enters, the applications that user can open, and the data range actually visible.
Academic-affairs staff may need to see course records only for grades their school is responsible for, while managers see school-level summaries. If some fields should not be displayed, configure column permissions for the dataset. The design must also confirm the application’s data-permission mode. If the dashboard uses a derived dataset, assess the derived dataset separately as a new access surface; do not assume upstream row permissions pass through automatically.
For acceptance, use accounts from both schools and different internal roles to check the same dashboard’s page, export, and derived dataset. A School A account should not see School B records, and a restricted role should not see grades or fields beyond its authorization. Record expected and actual results for every account. When there is a discrepancy, trace it back through sharing, secondary authorization, and permission sources.
HENGSHI’s multi-tenant capability provides independent spaces and layered authorization. Reliable data boundaries require tenant sharing, application permissions, and data permissions to be designed as one configuration set and verified across every user path.