New Features, Enhancements, and Fixes › Incident and Problem Management › Multi-Tenancy Enhancements

Multi-Tenancy Enhancements

CA Service Desk Manager now supports more sophisticated data sharing among tenants. In addition to enhanced data sharing, multi-tenancy also supports different products that share the same MDB. For example, CA Service Catalog also supports a tenant hierarchy of unlimited depth.

Important! If you want to configure Support Automation in a multi-tenancy environment, you must separately migrate CA Support Automation r6.0 SR1 eFix5 divisions to r12.5 tenants before enabling Support Automation in CA Service Desk Manager. For more information about migrating divisions to tenants, see the Implementation Guide.

Multi-tenancy includes the following enhancements:

• Tenant hierarchies, which permit subtenants (for example, departments or sites within a tenant) that contain separate business rules and data but also share some business data with their parent tenant. CA Service Desk Manager supports a tenant hierarchy that is limited to a depth of 40, although the service provider can specify a limit or declare that an individual tenant cannot have subtenants.
• More sophisticated data sharing among tenants. In previous releases, tenants could update only their own data, and only the service provider tenant could update data from other tenants. In CA Service Desk Manager r12.5, read and write access for a role can be specified independently, and the service provider can authorize a tenant to update other tenants. This functionality can be used to grant a tenant write access to its subtenants, but the architecture does not limit its application.
• Enhanced flexibility for CIs, including the following:
  • CIs with ambiguous identifying attributes (sometimes named duplicate CIs) are permitted as long as they belong to different tenants
  • Service provider CIs can be linked to tenant CIs
  • The Tenant Detail page displays the CIs associated with that tenant
  • The CI Detail page displays the tenants impacted by that CI
  • If a CI is shared among tenants, a tenant does not know that it is shared. Each tenant only sees its own data.
  • The service provider tenant can see the CIs and relationship for multiple tenants.
• Enhanced flexibility for Support Automation, including the following:
  • The system initially handles queries based on the tenant context of a user, followed by the public setting.
  • Administrators configure system options, specific to tenants or public environments.
  • Administrators customize Support Automation, such as privacy levels, branding, and configure queues for specific tenants, or for the system.
  • Administrators create tenants and default data is set to public, either in a non-tenanted table or with a null tenant in a tenant-optional table. These data objects include Live Assistance tools, localizations, conduit rules, system properties, the default queue, and so on.
  • Analysts and administrators with the appropriate role permissions and access to multiple tenants select the appropriate tenant when creating classifications and uploading scripts in the Automated Task Editor.
  • Analysts provide end-user support in the context of their tenant access. For example, analysts can only create assistance sessions for the tenants where they have write access.

    Important! Analysts without read access to their tenant cannot launch the Support Automation analyst client, and a warning message appears in CA Service Desk Manager, such as from the main Support Automation tab or a ticket.

  • Analysts belonging to the service provider tenant can enter an assistance session with an end user from any tenant. Tenant analysts can only enter sessions with end users from their own tenant and subtenants.

    Important! If a non-service provider analyst has write access to a parent, sibling, or unrelated tenant, function access must be updated for that tenant.

  • Analysts use Live Assistance tools, monitor queues, host assistance sessions, and so on, but are restricted to only the tenants where they have write access.
• Classes, families, and models are tenanted, and their respective lists and menus are tenant-restricted automatically.