Application support for domain separation

Many ServiceNow applications support domain separation in the base system but not all. Some supported applications include limitations on the data and administrative settings that can be domain-separated. These definitions delineate the domain separation support levels from the perspective of actual use cases and the people who use them.

Domain separation support levels

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 must be able to set up the application to function across multiple tenants.

Sample 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 must be able to configure the minimum viable product (MVP) business logic and data parameters per tenant as expected for the specific application.

Sample use case: An admin must 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 must 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.

Sample use case: Tenant-customers of a shared environment must be able to change to the impact, urgency, or priority matrix to set priority within their domain.

Note: Effective Domain (*)

Sometimes, a platform feature or application may effectively support SP use cases even without the domain framework. If so, the use cases must detail its support of domain separation. An asterisk (*) after the support level indicates this kind of configuration.

|Domain-specific configuration is managed by instance owner.|

|Tenant domains can manage their own application data.| |

|Application properties are domain aware when needed.| |

|Business logic and processes can be domain-separated by instance owner.| |

|Business logic and processes can be administered by the tenant domain.| | |

Support levels by application

Parent Topic:Domain separation for service providers