Limits and limitations

This section describes the tenant limits and limitations that you must be aware of when you deploy multiple tenants on the same instance.

Tenant limits per instance

The tenant limits per instance must align with the sizing recommendations based on the number of concurrent users defined for each category.

Additionally, ensure that tenants with similar or equivalent sizes are deployed on the same instance to prevent larger tenants from consuming excessive resources. For instance, if the small sizing category supports up to 500 concurrent users, it's more effective to deploy five tenants with approximately 100 concurrent users each rather than two tenants with 400 and 100 users.
Furthermore, to ensure optimal application performance and enhance user experience, tenants must be deployed in the region closest to the cluster, minimizing network latency.

Unsupported scenarios

The BMC Helix ITSM company construct focuses on the segregation of data users will see while working on the product.

The company model does not segregate the code (e.g., workflow) executed. In the BMC Helix ITSM application, the code refers to the following:

• Active links
• Filters
• Escalations
• Menus
• Forms
• Workflow

These are common across all tenants who are logging into the environment. Therefore, any changes to workflow specific to a tenant are not supported. These changes can become visible or affect the business logic of other companies running in that environment.

CMDB changes are global to all tenants, so any changes made to the CMDB must be made and exposed to all tenants. Any changes to the CMDB that can be made visible to only a single tenant is not supported.

The ITOM solutions currently do not support data segregation when used with ITSM. Only BMC Helix Dashboards uses the Organization Structure, which is synced from ITSM companies, to segregate the definition of dashboards.