{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":4941,"path":"conversational-interfaces/virtual-agent/domain-separation-virtual-agent.md","title":"Domain separation and Virtual Agent","bundle":null,"doc_type":null,"release":"australia","body":"\n# Domain separation and Virtual Agent\n\nDomain 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.\n\n## Support level: Standard\n\n-   Includes all aspects of **Basic** level support.\n-   Application properties are domain-aware as needed.\n-   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.\n-   The instance owner must configure the minimum viable product \\(MVP\\) business logic and data parameters per tenant as expected for the specific application.\n\nSample use case: An admin must be able to make comments required when a record closes for one tenant, but not for another.\n\nFor more information on support levels, see [Application support for domain separation](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/platform-security/domain-separated-apps.md).\n\nDomain 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.\n\nDomain separation in Virtual Agent works by creating separate Virtual Agent views that are isolated from each other. The chat configuration, branding, NLU settings, 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.\n\nDomain separation is best for customers with any of the following requirements:\n\n-   You need to enforce absolute data segregation between business entities \\(data separation\\).\n-   Customize business process definitions and user interfaces for each domain \\(delegated administration\\).\n-   Maintain some global processes and global reporting in a single instance.\n-   Separate data between customers or sub-organizations.\n-   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.\n-   The record scope uses the domain of the record and is active when viewing the form of any record.\n\n    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.\n\n    **Note:** Users always have access to data from domains that have been explicitly granted to them by domain visibility.\n\n\nWhen 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/australia/markdown/australia/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/australia/markdown/australia/conversational-interfaces/virtual-agent/associate-domain-id-chat-portal.md).\n\nFor more information, see [Domain scope](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/platform-security/c_DomainScope.md).\n\n## Requirements\n\nAll 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/australia/markdown/platform-security/t_ActivateDomainSeparation.md).\n\n## Configuring Virtual Agent with domain separation\n\n-   **Branding**\n\n    Service providers can create a [chat branding configuration](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/conversational-interfaces/ac-configure-chat-branding.md) per domain.\n\n-   **[Chat experiences](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/conversational-interfaces/virtual-agent/va-conversation-settings.md)**\n\n    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.\n\n-   **NLU settings**\n\n    Only one NLU service provider can be set per domain-separated instance for all Virtual Agent clients. The managed service provider \\(MSP\\) logs in as a global user for the domain to configure NLU. For details, see [Configure Natural Language Understanding in Virtual Agent](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/conversational-interfaces/virtual-agent/configure-nlu-settings.md).\n\n\n## Creating topics in subdomains in Assistant Designer\n\n**Roles required:** admin or virtual\\_agent\\_admin\n\nThe 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/australia/markdown/australia/conversational-interfaces/virtual-agent/create-virtual-agent-topic.md) and [publish](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/conversational-interfaces/virtual-agent/publish-virtual-agent-topic.md) their own topics.\n\nTopic 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**.\n\nOnly service provider admins can do the following:\n\n-   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.\n-   Assign roles on a particular subdomain to control which topics can be run by users.\n\nAdmin users assigned to the subdomain can do the following:\n\n-   Create topics in the instance.\n-   Be logged into the global domain and impersonate a user in the subdomain.\n-   Publish all available topics in the subdomain to chat widgets and messaging applications.\n\n## Domain separation in the chat widget channel\n\nThe 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.\n\nTo configure the portal, see [Associate a domain ID with a chat portal](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/conversational-interfaces/virtual-agent/associate-domain-id-chat-portal.md).\n\nFor information about URL parameters, see [Virtual Agent URL parameters](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/conversational-interfaces/virtual-agent/va-sysparm.md).\n\n## Domain separation and Virtual Agent messaging app integrations\n\n**Roles required:** admin or virtual\\_agent\\_admin\n\nThe domain-separated instance has one setup record for Slack, Microsoft Teams, Workplace, or Facebook Messenger.\n\nCustomers on the subdomain license either Slack, Microsoft Teams, or Workplace independently of the ServiceNow instance.\n\nThe 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/australia/markdown/australia/conversational-interfaces/virtual-agent/va-integration-messaging-apps.md).\n\nFor Facebook Messenger, the admin manually configures the integration. For details, see [Conversational Integration with Facebook Messenger](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/conversational-interfaces/virtual-agent/messg-fbm.md).\n\n-   **[Associate a domain ID with a chat portal](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/conversational-interfaces/virtual-agent/associate-domain-id-chat-portal.md)**  \nThe Service Portal platform is not domain-separated, but you can create different versions of a portal and restrict each version's use to a single domain for chat purposes. For example, you could create two employee service portals and define a different domain for each.\n\n**Parent Topic:**[Virtual Agent technical reference](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/conversational-interfaces/virtual-agent/va-advanced-technical-reference.md)\n\n**Related topics**  \n\n\n[Virtual Agent interaction records]()\n\n[Virtual Agent scripts]()\n\n[Input data types in Virtual Agent topics]()\n\n[NLU system entities]()\n\n[Virtual Agent URL parameters]()\n\n[Latency feedback in Virtual Agent]()\n\n[Domain separation for service providers](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/platform-security/domain-sep-landing-page.md)\n\n"}}