Domain separation and Virtual Agent
Summarize
Summary of Domain separation and Virtual Agent
Domain separation in the Virtual Agent application allows ServiceNow customers to partition data, processes, and administrative tasks into isolated logical groupings called domains. This separation ensures that users and administrators can only access Virtual Agent conversations and configurations relevant to their assigned domain, enhancing security and data segregation in multi-tenant environments. It supports environments where multiple business entities or customers share the same ServiceNow instance but require strict data and process isolation.
Show less
Key Features
- Domain-Aware Configuration: Chat configurations, branding, NLU settings, topics, and components are assigned and scoped per domain, enabling tailored Virtual Agent experiences.
- Access Control: Users can only view and interact with Virtual Agent conversations within their domain. Domain administrators cannot access other domains’ conversations, ensuring data privacy.
- Session and Record Scope: Users’ session domain scope is set based on their user record, with the ability to manually switch domains. Record scope defaults to the domain of the record and can override session scope, allowing controlled visibility into child or parent domains as permitted.
- Branding and Chat Experiences: Service providers can create domain-specific chat branding and chat experiences, including custom topics and overrides, to deliver unique interactions per domain.
- Topic Management: Topics must be uniquely named within a domain but can be duplicated across domains. Both service provider admins and domain admins have defined roles for creating, publishing, and managing topics.
- Integration with Messaging Apps: Domain-separated instances support integrations with Slack, Microsoft Teams, Workplace, and Facebook Messenger, with configuration managed at the domain/subdomain level.
- Chat Widget and Portals: The chat widget itself does not support domain separation, but separate domain-specific portals can be created and associated with domain IDs to simulate domain separation in chat widget channels.
- Plugin Requirement: Domain separation features require the Domain Support - Domain Extensions Installer plugin to be enabled.
Practical Benefits and Use Cases
- Enforces strict data segregation between business units, customers, or sub-organizations sharing a ServiceNow instance.
- Enables delegated administration where each domain can customize business processes, user interfaces, and Virtual Agent configurations independently.
- Supports service providers managing multiple tenants by allowing global processes alongside domain-specific customizations and reporting.
- Improves security by restricting guest users and domain admins to their respective domains.
- Facilitates multi-tenant Virtual Agent deployments in complex organizational or managed service provider environments.
Configuration and Administration
- Service providers or domain admins create and manage topics and chat experiences scoped to each domain.
- Only service provider admins can activate Virtual Agent conversation plugins and assign roles controlling topic access per domain.
- Administrators configure domain IDs within Service Portals to restrict chat portal access to specific domains.
- NLU settings are managed globally but apply per domain for consistent natural language understanding.
What to Expect
By implementing domain separation in Virtual Agent, ServiceNow customers can expect enhanced data isolation, customized chatbot experiences per domain, and secure, delegated administration in multi-tenant or complex organizational scenarios. This capability ensures that Virtual Agent conversations, configurations, and integrations respect domain boundaries, providing confidence in data privacy and operational control across distributed teams or customers within a single ServiceNow instance.
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.
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.
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, 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.
- 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 always 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 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.
For more information, see Domain scope.
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.
Configuring Virtual Agent with domain separation
- Branding
- Service providers can create a chat branding configuration per domain.
- Chat experiences
- 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.
- NLU settings
- 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.
Creating topics in subdomains in Virtual Agent 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 and publish 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.
- 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.
- 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.
For information about URL parameters, see Virtual Agent URL parameters.
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, Microsoft Teams, Workplace, or Facebook Messenger.
Customers on the subdomain license either Slack, Microsoft Teams, or Workplace 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.
For Facebook Messenger, the admin manually configures the integration. For details, see Conversational Integration with Facebook Messenger.