When you enable multi-tenancy, you can grant each contact (user) access to all tenants (public), a single tenant, or a tenant group (user-defined or system-maintained). The role for a contact controls access, which specifies read and write access independently. Because tenant access is role-dependent and a contact can change roles during a session, tenant access for a contact can change.
In a multi-tenancy implementation, most data objects include a tenant attribute that specifies which tenant owns the object. Objects belong to the following 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. The product, not the database management system, enforces this restriction. All data in these objects is associated with individual tenants, not 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 views the object in a merged view of the public data and their tenant-specific data.
Examples: Category and location.
|
Copyright © 2013 CA.
All rights reserved.
|
|