Domain separation and Dynamic Translation
Summarize
Summary of Domain Separation and Dynamic Translation
Domain separation in Dynamic Translation allows ServiceNow users to organize data and processes by logically grouping them into domains. This feature enables precise control over data visibility and access, ensuring that users interact only with the information pertinent to their domain while maintaining the integrity of the service provider's responses to tenant customers.
Show less
Key Features
- Separation of Data: Dynamic Translation supports domain separation at runtime, impacting user interfaces, cache keys, reporting, and more.
- Translator Configurations: Users can access translation service providers configured for their domain, with configurations from the parent and global domains available for use.
- Default Translator Configurations: The current domain's default translator configuration is prioritized for dynamic translation; if absent, the nearest parent domain's configuration is utilized.
- Overriding Configurations: Translator configurations can be overridden in a domain, affecting visibility and reference to parent configurations.
Key Outcomes
By implementing domain separation with Dynamic Translation, ServiceNow customers can enhance their translation services by ensuring that users have streamlined access to relevant translations while maintaining data integrity across multiple domains. This setup is crucial for service providers managing interactions with various tenants, enabling efficient response handling and tailored translation services.
Domain separation is supported in Dynamic Translation and is configured to apply to translator configurations. Domain separation enables you to separate data, processes, and administrative tasks into logical groupings called domains. You can control several aspects of this separation, including which users can see and access data.
Support level: Basic
- Business logic: Ensure that data goes into the proper domain for the application’s service provider use cases.
- The application supports domain separation at run time. The domain separation includes separation from the user interface, cache keys, reporting, rollups, and aggregations.
- The owner of the instance must set up the application to function across multiple tenants.
Sample use case: When a service provider (SP) uses chat to respond to a tenant-customer’s message, the customer must be able to see the SP's response.
For more information on support levels, see Application support for domain separation.
Activation information
You should activate the Domain Support - Domain Extensions Installer plugin (com.glide.domain.msp_extensions.installer). For information on how you can request for the plugin activation, see Request for domain separation in Dynamic Translation.
How domain separation works in Dynamic Translation
A service provider with domain separated instances can implement the Dynamic Translation framework so that users can use the translation service providers configured in the translator configurations specific to their domain. Translator configurations are process-separated in Dynamic Translation. All translation service providers configured in the translator configurations of the parent domain are available in child domains.
- Current domain
- Parent domains
- Global domain
Also, different connections can be configured for the same connection and credential alias of a translation service provider in multiple domains. However, Credentials and Connections are data-separated. So, a connection configured in a child domain is visible in parent domains. For information on domain separation for Connections and Credentials, see Domain separation for Credentials and Connections.
For example, consider the following scenario:
- Connection1
- Connection2
- Connection3
Domain-separated table
Translator Configuration [sn_dt_translator_configuration].
Default translator configuration for a domain
The default translator configuration of the current domain is always considered for dynamic translation. If the current domain does not have any default translator configuration, then the available default translator configuration of the nearest parent is considered.
A domain can have multiple default translator configurations. In this case also, the default translator configuration of the current domain is considered for dynamic translation. For example, let us consider the following scenario:
In Domain B, both TC1 and TC2 are visible. From Domain B, TC2 is first set as the default translator configuration. From Domain A, TC1 is then overridden and set as the default translator configuration. This results in multiple default translator configurations in Domain B. In this case, when in Domain B, TC2 is used as the default translator configuration for dynamic translation.
Overriding a translator configuration
In any domain, you can override the translator configuration of that domain or the parent domain. The overridden translator configuration of a parent domain is also visible in child domains. However, the overridden translator configuration of a child domain is not visible in the parent domain.
After you override a translator configuration of the same domain, only the overridden translator configuration is visible in that domain.
- Only the overridden translator configuration is visible in the child domain.
- The Overrides field of overridden translator configuration refers to the original translator configuration of the parent domain.
For example, consider the following scenario:
You can override a translator configuration TC1 from Domain B. After overriding, only the overridden configuration TC1 is available in Domain B and the Overrides field of TC1 refers to TC1 of the parent domain.