Domain separation support levels
Note: The definitions of the support levels for domain separation have been updated to more
accurately describe configurations and use cases that fit each application. Please take a
moment to study the new descriptions.
ServiceNow applications
that support domain separation may support the separation of data and data routing only,
have advanced business logic separation, or support tenant (customer) level administration
of the application.
ServiceNow applications are defined with the
following incremental support levels..
No support
- The domain field may exist on data tables, but no logic exists to manage data.
- This level is not considered domain-separated.
Basic
- Business logic: Ensure data goes into the proper domain for the application’s service
provider (SP) use cases.
- In the application, the user interface, cache keys, reporting, rollups, aggregations,
and so on, all use domain at production run time.
- The owner of the instance needs to be able to set up the application to function
across multiple tenants.
Use case: When an SP uses chat to respond to a tenant-customer’s message, the client
must be able to see the SP's response.
Standard
- Includes Basic level support.
- Business logic: Processes can be created or modified per customer by the service
provider (SP). The use cases reflect proper use of the application by multiple SP
customers in a single instance.
- The owner of the instance needs to be able to configure the minimum viable product
(MVP) business logic and data parameters per tenant as expected for the specific
application.
Use case: An admin needs to be able to make comments mandatory when a record closes for
one tenant but not for another.
Enhanced
- Includes Basic and Standard levels
- Data-driven process enables service provider customers to modify business logic that
is based on defined use cases. These configurations are UI-based and fail-safe so that
configurations by one customer cannot affect another.
- Tenants of the instance need to be able to configure minimum viable product (MVP)
business logic and data parameters for themselves. This logic and parameters would be
expected for the application's normal function.
Use case: Tenant-customers of a shared environment need to be able to make changes to
the impact, urgency, or priority matrix to set priority within their domain.
Note: Effective Domain
(*)
- In some cases a platform feature or application may be able to effectively support SP
use cases even though the domain framework is not being used.
- Should that be the situation, the use cases must be specifically detailed to support
domain separation. An asterisk (*) after the support level
indicates this kind of configuration.
Use case: Before the New York release, Service Catalog had no domain support but the
instance owner was able to configure separate catalogs and items for each tenant in a
domain-separated instance using user criteria. This allowed Service Catalog to be used as if
it were Standard, giving it a
Standard* rating.
*In some cases a platform feature or application may be able to effectively support service
provider uses cases even though the domain framework is not being used. In this situation
the use cases must be specifically detailed to support domain separation. An asterisk (*)
after the support level indicates this kind of configuration.
