Multi-tenant Objects Isolation Additional Information

Project Duplication

Tenant users can duplicate projects within their own tenant.

If you are using a version prior to Strategy (September 2026), cross-environment project duplication is not supported for tenant users. If you are using Strategy (September 2026) or later, cross environment project duplication is supported for tenant administrators.

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.

Starting in Strategy (September 2026), tenant administrators can duplicate projects across environments. See the following information on the current behavior for project backup and restoration when migrating project data between source and target environments. Administrators can use the following information to understand which objects are included in a project backup, how object ownership affects restore behavior, and how conflicts are resolved during import.

Note: In the following sections, source refers to the environment and tenant from which the backup is created. Target refers to the environment into which the backup is imported. Tenant objects are owned by a specific tenant and Global objects are shared at the environment-level.

Backup Scope and Object Ownership

When a tenant administrator creates a project backup from Tenant A, the export process applies the following object-scope rules:

Object ID Conflict Resolution Logic

When a backup is imported into the target environment, object ID conflicts are resolved according to object ownership and whether an equivalent object already exists in the target.

Note: A tenant mismatch error is a blocking restore failure. It occurs when a tenant-owned source object conflicts by ID with a global object or with an object owned by another tenant in the target environment. Administrators should review ownership and object identity before retrying the import.

Object Name Matching Behavior

When Match by Name is enabled, the restore results depends on the administrator context and whether the source and target objects have compatible ownership scopes.

Global Administrator

A global administrator can manage objects across tenants. The following behavior applies when restoring with a global administrator.

Global administrators can tolerate cross-tenant object-name conflicts. For those conflicts, the system does not reuse a target object solely because it has the same name. Instead, it falls back to the matching object ID.

Tenant Administrator

A tenant administrator operates within a specific tenant. The following behavior applies when restoring with Tenant Administrator privileges.

Note: For tenant administrators, a name conflict between a Tenant A object and a global object block import condition. Resolve the naming conflict or perform the restore with an administrator context that supports the required cross-scope handling.

Summary

• Global administrators can tolerate cross-tenant object-name conflicts by falling back to ID matching.
• Tenant administrators can not import a tenant object when its name conflicts with a global object.
• Tenant-to-tenant name conflicts are not treated as name matches; the system falls back to ID matching.

User Login Matching Behavior

User matching is controlled by two settings:

• Match by Login
• OM/CrossTenantDuplicateUsername feature flag

The current behavior is the same for global administrators and tenant administrators.

Match by Login Disabled

Matched by Login Enabled

Note: When Match by Login is enabled and the feature flag is OFF, a login conflict with a global user or a user from another tenant causes the import to fail. Enable the feature flag or resolve the conflicting login before retrying the restore.

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.