EducationSoftwareStrategy.com
StrategyCommunity

Knowledge Base

Product

Community

Knowledge Base

TopicsBrowse ArticlesDeveloper Zone

Product

Download SoftwareProduct DocumentationSecurity Hub

Education

Tutorial VideosSolution GalleryEducation courses

Community

GuidelinesGrandmastersEvents
x_social-icon_white.svglinkedin_social-icon_white.svg
Strategy logoCommunity

© Strategy Inc. All Rights Reserved.

LegalTerms of UsePrivacy Policy
  1. Home
  2. Topics
  3. Multi-tenant Objects Isolation Additional Information

Multi-tenant Objects Isolation Additional Information

Strategy One (March 2026) adds support for metadata-level multi-tenancy to host and manage multiple tenants within a single platform deployment. This preview feature has some additional information for various functions, described below.

Project Duplication

Tenant users can duplicate projects within their own tenant. Cross-environment project duplication is not supported for tenant users.

Key behaviors:

  • Tenant mismatch protection: If an object exists in both the source and target environments but belongs to different tenants, the duplication is rejected to prevent data conflicts.
  • Cross-tenant reference protection: If a duplication would create a reference between objects in different tenants, the operation is rejected to maintain tenant isolation.

Package Migration

Tenant administrators can migrate objects within their own tenant.

Global administrators have broader migration capabilities:

  • Migrate objects within the same tenant.
  • Migrate objects between different tenants, subject to the following rules:
    • If the package contains only project objects from Tenant A, those objects can be successfully migrated to Tenant B.

    • If the package contains project objects from Tenant A along with global configuration objects and the target environment does not have the same configuration objects assigned to other tenants, the migration succeeds. Project objects are assigned to Tenant B and configuration objects will remain global.

    • If the package contains both project objects and tenant-scoped configuration objects from Tenant A, importing to Tenant B is not supported. Changing a configuration object's tenant association during migration is not permitted.

Note: Package migration never changes the tenant association of configuration objects. Additionally, cross-tenant references (for example, a project object in Tenant A that references a configuration in Tenant B) are not allowed and are flagged during migration.

Search and Discovery

Multi-tenancy enforces strict content isolation in search. See the following search information:

  • Search results include only objects within your tenant and globally shared objects, governed by access control lists (ACLs).
  • Content that belongs to other tenants is not visible or accessible.
  • Tenant-aware search is supported in both Workstation and Library via Global Search.

Environment-Level Settings

In a multi-tenancy-enabled environment, access to environment-level operations is governed by role-based enforcement:

  • Global administrators have full access to environment-level settings, global objects, and system objects.
  • Tenant users and tenant administrators are restricted from operations that affect environment-level settings, global objects, or system objects, even if they hold relevant privileges.

Note: Tenant administrators are permitted to configure Subscription Delivery Settings if they have the correct privileges.

Governing Settings

Administrators can set limits to the number of users and projects per tenant to maintain resource governance.

Use the following Library Admin REST API calls to retrieve and update governing settings:

  • GET /api/multitenant/tenant/{tenantId}/settings: Retrieve the governing settings for a specific tenant.
  • PATCH /api/multitenant/tenant/{tenantId}/settings: Update the governing settings for a specific tenant.

Monitors

In a multi-tenancy-enabled environment, each monitored item is associated with a tenant so tenant administrators can only view the activity within their own tenant. Global administrators view activity across all tenants. The tenant of a monitored item is determined as follows:

  • User Connections: The tenant of the connected user.
  • Jobs: The tenant of the user who submitted the job.
  • Caches and Cubes: The tenant of the project they belong to.
  • Database Connections: The tenant of the user who creates the connection. Unlike other monitors, this monitor is available only to global administrators.
  • Subscriptions: The tenant of the subscription's owner.
  • Contacts and Contact Groups: The tenant of the linked user.

Authentication

In a multi-tenancy-enabled environment, if a user needs to be imported or synced during JWT/Trust authentication login, see the following knowledge base article for more information, Import Users During JWT or Trust Login.

If a tenant user wants to log in to the environment using the REST API api/auth/login, set the correct applicationID parameter. The applicationID must belong to an application within the same tenant or it can be left as the default value.

Change Journal

In a multi-tenancy enabled environment, change journal access is governed by tenant-scoped visibility and permission controls.

Global administrators have full access to the change journal, including the ability to browse and purge entries for all objects and projects across all tenants.

Tenant administrators have scoped access within their own tenant:

  • Browse: Tenant administrators can view change journal entries for objects within their own tenant. Entries related to global objects, objects from other tenants, operations performed by users outside the tenant, and object deletion records are not visible.
  • Purge: Tenant administrators can purge change journal entries for projects within their own tenant. Purging change journal entries for configuration objects is not permitted.

Troubleshooting: Tenant Isolation Errors

Tenant partitioning enforces strict tenant isolation boundaries. The following errors may occur when an operation violates these boundaries. Use the following troubleshooting information to avoid unsupported operations and resolve issues.

Cross-Tenant Reference Violation

Cross-tenant reference violation occurs when an operation would create a dependency between objects that belong to different tenants, or between a global object and a tenant-scoped object. This action is blocked to preserve tenant isolation.

Common Scenarios:

  • Reassign an object's tenant in the following scenarios:
    • Assigning a global database role to a tenant when its referenced database connection belongs to a different tenant.
    • Reassigning a database role to Tenant B when a Tenant A dashboard depends on it.
    • See the following example error: DB Instance object DBInstance_Global (ID: 948A5C7F4B4DC3FCF0FD4885576ECF9E) cannot use DB Connection object DBConnection_TenantA (ID: DDF6918B443FF3D69BFDE7BF8F575B2D) due to tenant conflicts.
  • Modify a reference relationship in the following scenarios:

    • Add a Tenant B user to a Tenant A user group.

    • Configure a global database role to use a tenant-scoped database connection.

    • See the following example error: DB Instance object DBInstance_Global (ID: 948A5C7F4B4DC3FCF0FD4885576ECF9E) cannot use DB Connection object DBConnection_TenantB (ID: DDF6918B443FF3D69BFDE7BF8F575B2D) due to tenant conflicts.

  • Package migration introducing cross-tenant references in the following scenarios:
    • Importing a package that contains a Tenant A dashboard referenced in a Tenant A database role into a Tenant B project (where a database role does not already exist in the target environment) will be rejected.
    • See the following example error: The object DBInstance_TenantA with ID '993932B14D29FC43EBE48DB150437E97' and type 'DB Instance' is under an unreferenceable tenant.

Exceptions

  • If you assign a global user group to a tenant, all its member users are automatically assigned to that tenant.
  • A global user that joins a tenant-scoped user group is automatically assigned to that tenant.

Tenant Conflict During Migration

Tenant conflicts during migration occur when an operation would change an object's tenant association during migration, which is not permitted. If the same object exists in both the source package and the target environment but belongs to different tenants, the migration is rejected.

Common Scenarios:

  • Package migration in the following scenarios:
    • An object in the package belongs to Tenant A, but the same object in the target environment belongs to Tenant B. The migration is rejected to prevent an implicit tenant assignment.
    • See the following example error: A tenant conflict occurs for the object User with ID 'D06A23F1493886DE189FA48C596BC91C' and type 'User'.

  • Project duplication in the following scenarios:
    • An object in the backup belongs to a different tenant than the corresponding object in the target environment. The duplication is rejected.
    • See the following example error: Project Duplication Error: Tenant Mismatch: Object 'rest'(ID: 0F3A1B784E457E442AA1DBB564DA57A7) Incoming Tenant: 00000000000000000000000000000000.


Comment

0 comments

Details

Knowledge Article

Published:

March 18, 2026

Last Updated:

July 1, 2026