Defining Business Structure › Multi-Tenancy › How Multi-Tenancy Works

How Multi-Tenancy Works

When multi-tenancy is active, you can grant each contact access to all tenants (public), a single tenant, or a tenant group (user-defined or product-maintained). A contact's role controls access, which specifies read and write access independently. Because tenant access is role-dependent and a contact can change roles during a session, contact tenant access also can change.

If multi-tenancy is installed, most CA SDM objects include a tenant attribute that specifies which tenant owns the object. Objects fall into three groups, depending on their tenant attribute and how it is used:

Untenanted

Defines objects without a tenant attribute. All data in these objects is public.

Examples: Priority and urgency.

Tenant Required

Defines objects with a tenant attribute that cannot be null (enforced by CA SDM, not the DBMS). All data in these objects is associated with individual tenants; there is no public data.

Examples: Ticket tables (Request, Issue, and Change Order).

Tenant Optional

Defines objects with a tenant attribute that can be null. Some of the data in these objects is public, and some is associated with specific tenants. Each tenant's view of the object is a merged view of the public data and their tenant-specific data.

Examples: Category and location.

When a user queries the database, CA SDM restricts the results to objects belonging to tenants that the user is authorized to access. This restriction applies in addition to any data partition restrictions that are in effect. This means that you never see data in tenant required and tenant optional tables except for the data that belonging to tenants that you are permitted to access.

When a tenant user asks to create or update a database object, CA SDM verifies that the object belongs to a tenant that the user's current role allows them to update, and that all foreign key (SREL) references from the object to other objects are to public (untenanted) objects; to objects from the same tenant; or to objects from tenants in the tenant hierarchy above the object's tenant. That is, a tenanted object is allowed to reference objects belonging to its parent tenant, to its parent's parent, and so on.

If a user that creates an object has update access to multiple tenants, the user must specify the tenant explicitly, either directly or indirectly.

Note: There is one exception to the SREL reference restriction. Certain SREL references (such as the assignee of an incident) are permitted to reference objects that belong to tenants in their containing object's tenant hierarchy. Such references are designated as SERVICE_PROVIDER_ELIGIBLE in the CA SDM object schema (the Majic). The SERVICE_PROVIDER_ELIGIBLE flag makes a difference only if the service provider tenant is not in the tenant hierarchy above the object's tenant; if the service provider tenant is in the hierarchy, tenant validation rules permit service provider references.

A service provider user asking to create or update an object is subject to the same restrictions as tenant users, except that service provider users can be authorized to create or update public objects. The active role of the service provider user controls this authorization.

Note: If CA SDM limits a user from updating tenant data, an error message can announce a data partition limitation. If you receive this error message, either data partition or multi-tenancy restrictions are in effect.