Multi-tenant Objects Isolation Additional Information

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 will be rejected to prevent data conflicts.
• Cross-tenant reference protection: If a duplication would create a reference between objects in different tenants, the operation will be 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 will succeed. Project objects will be 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. This is due to 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 will be 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 (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: An exception is 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.

See 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 that creates the connection. Unlike other monitors, this monitor is available to global administrators only.
• 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 synched 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.

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 is 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:
• Assigning a global database role to a tenant when its referenced database connection belongs to a different tenant.
• Reassign 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:

• 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:
• Importing a package that contains a Tenant A dashboard and is 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

• Assign a global user group to a tenant will automatically assign all its member users to that tenant.
• A global user that joins a tenant-scoped user group will automatically be assigned to that tenant.

Tenant Conflict During Migration

Tenant conflicts during migration is 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:
• 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:
• An object in the backup belongs to a different tenant than the corresponding object in the target environment. The object duplication is rejected.
• See the following example error: Project Duplication Error: Tenant Mismatch: Object 'rest'(ID: 0F3A1B784E457E442AA1DBB564DA57A7) Incoming Tenant: 00000000000000000000000000000000.