--- title: Domain separation and Virtual Agent description: Domain separation is supported in the Virtual Agent application. 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. Virtual Agent has standard support. ServiceNow Otto for Virtual Agent has basic support. locale: en-US canonical_url: https://www.servicenow.com/docs/r/conversational-interfaces/virtual-agent/domain-separation-virtual-agent.html release: brazil product: Virtual Agent classification: virtual-agent topic_type: concept last_updated: "2026-09-10" reading_time_minutes: 6 keywords: [Virtual Agent, domain, separation, support] breadcrumb: [Explore, Virtual Agent, Conversational Interfaces] --- # Domain separation and Virtual Agent Domain separation is supported in the Virtual Agent application. 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. Virtual Agent has standard support. ServiceNow Otto for Virtual Agent has basic support. ## Support level: Standard - Includes all aspects of **Basic** level support. - Application properties are domain-aware as needed. - Business logic: The service provider \(SP\) creates or modifies processes per customer. The use cases reflect proper use of the application by multiple SP customers in a single instance. - The instance owner must 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 required when a record closes for one tenant, but not for another. For more information on support levels, see [Application support for domain separation](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/platform-security/domain-separated-apps.md). ## 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](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/platform-security/domain-separated-apps.md). Domain separation allows you to partition your organization's data and administrative control into separate domains. This lets you isolate the data and control access to it, which is particularly important in environments where multiple tenants share a common platform. Domain separation in Virtual Agent works by creating separate Virtual Agent views that are isolated from each other. The chat configuration, branding, and topics and components can be assigned to a given domain within Virtual Agent. Users within a domain can only access the Virtual Agent conversations that are associated with their domain. This means that users in one domain cannot access data or functionality that belongs to another domain, including Virtual Agent conversations. Additionally, administrators who are assigned to a domain cannot see or manage Virtual Agent conversations in other domains, ensuring complete separation and security. Domain separation is best for customers with any of the following requirements: - You need to enforce absolute data segregation between business entities \(data separation\). - Customize business process definitions and user interfaces for each domain \(delegated administration\). - Maintain some global processes and global reporting in a single instance. - Separate data between customers or sub-organizations. - The session scope is set upon session establishment to the domain listed in the user's user record. Users can manually change their session domain scope with the domain picker. - The record scope uses the domain of the record and is active when viewing the form of any record. By default, the record scope takes precedence over the session scope so that users in higher-level domains adhere to each record's data and process constraints. However, these users can choose to expand or collapse the domain scope to show or hide data from other domains. For example, a user in the service provider \(SP\) global domain also has visibility into child domains such as the ACME domain. When looking at an incident record from the ACME domain, the user can choose to expand the domain scope to show values from the MSP domain or collapse the domain scope to show only record values that match the record's ACME domain. **Note:** Users have access to data from domains that have been explicitly granted to them by domain visibility. When domain separation is used, guest users are restricted to the domain used in the session. For custom chat channels, the domain of the [provider application](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/conversational-interfaces/virtual-agent/create-channel-id-va-cccif.md) is used. For the chat widget, you can associate a domain ID with the chat portal. For details, see [Associate a domain ID with a chat portal](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/conversational-interfaces/virtual-agent/associate-domain-id-chat-portal.md). For more information, see [Domain scope](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/platform-security/c_DomainScope.md). ## Requirements All domain support features require the Domain Support - Domain Extensions Installer \[com.glide.domain.msp\_extensions.installer\] plugin. For details, see [Request domain separation](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/platform-security/t_ActivateDomainSeparation.md). ## Configuring Virtual Agent with domain separation - **Branding** Service providers can create a [chat branding configuration](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/conversational-interfaces/ac-configure-chat-branding.md) per domain. - **[Chat experiences](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/conversational-interfaces/virtual-agent/va-conversation-settings.md)** Chat experiences, including the default experience and any custom experiences, allow for domain separation. Each chat experience profile belongs to a domain. Each child customization, such as a setup topic change, belongs to a domain. Each child customization implements system overrides so that sub-domains can override parent-domain customizations. ## Creating topics in subdomains in Assistant Designer **Roles required:** admin or virtual\_agent\_admin The service provider either logs in to one of the subdomains and creates and publishes topics or allows subdomain admin users to [create](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/conversational-interfaces/virtual-agent/create-virtual-agent-topic.md) and [publish](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/conversational-interfaces/virtual-agent/publish-virtual-agent-topic.md) their own topics. Topic names within a domain must be unique, but Virtual Agent does allow you to create topics with the same name in other domains. For example, each domain might have a topic called **Greeting**. Only service provider admins can do the following: - Activate Virtual Agent conversation plugins or store apps for other ServiceNow business applications, such as ITSM, CSM, or HRSD, to enable pre-built topics for the subdomain. - Assign roles on a particular subdomain to control which topics can be run by users. Admin users assigned to the subdomain can do the following: - Create topics in the instance. - Be logged into the global domain and impersonate a user in the subdomain. - Publish all available topics in the subdomain to chat widgets and messaging applications. ## Domain separation in the chat widget channel The chat widget does not support domain separation. However, you can provide a domain-separated chat experience in the chat widget channel by using separate, domain-separated portals. For example, you can create two separate support portals that are restricted to separate domains. Use the **domain\_id** in the portal script to designate the domain. This gets passed as the **sysparm\_domain\_id** parameter in the portal URL. To configure the portal, see [Associate a domain ID with a chat portal](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/conversational-interfaces/virtual-agent/associate-domain-id-chat-portal.md). For information about URL parameters, see [Virtual Agent URL parameters](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/conversational-interfaces/virtual-agent/va-sysparm.md). ## Domain separation and Virtual Agent messaging app integrations **Roles required:** admin or virtual\_agent\_admin The domain-separated instance has one setup record for Slack or Microsoft Teams. Customers on the subdomain license run either Slack or Microsoft Teams independently of the ServiceNow instance. The admin of the subdomain installs the integrations within the subdomain and configures the appropriate credentials to access Virtual Agent from the third-party client. For details, see [Integrating Virtual Agent with messaging apps](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/conversational-interfaces/virtual-agent/va-integration-messaging-apps.md). **Related topics** [Domain separation for service providers](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/platform-security/domain-sep-landing-page.md)