Using multiple active conversations in Virtual Agent
Summarize
Summary of Using multiple active conversations in Virtual Agent
ServiceNow's Virtual Agent now supports managing multiple active conversations simultaneously, each isolated by context. This eliminates the previous limitation where only one conversation with a shared history was possible across all portals, such as Service Portal (SP) and Employee Service Center (ESC). With this feature, each conversation remains fully independent, preventing overlap and ensuring separate transcripts per portal context.
Show less
For Natural Language Understanding (NLU) chats, context values must be configured to enable multiple active conversations. Large Language Model (LLM) chats automatically support this per portal, and administrators can activate an LLM assistant for each portal via guided setup configurations.
Benefits
- Context Isolation: Prevents sensitive information exposure by ensuring conversation histories do not carry over between different portal contexts (e.g., HR vs. IT portals).
- Continuous Engagement: Users can switch between portals or topics without losing conversation continuity or exposing unrelated chat history.
- Simplified Configuration: Requires no scripting or extensive customization to maintain separate conversations and route messages appropriately.
- Context-Appropriate Notifications: Users receive relevant updates like incident notifications tailored to their current portal context.
Implementation Considerations
- Administrators should define portal consumer context values and set or update a default context before activating the multiple active conversations system.
- Notifications must be configured to route correctly to the appropriate portals based on context.
- If the default Service Portal context suffices, additional context configuration can be skipped.
- Topics should be created within portal contexts to align with consumer account contexts for accurate message routing.
Key Configuration Steps
- Set NLU Portal Consumer Context Values: Determine which portals receive specific Virtual Agent messages and notifications based on user context.
- Set Default NLU Context Value: Define where messages are directed by default when multiple active conversations are enabled.
- Activate Multiple Active Conversations: Enable the system alongside defined contexts to manage concurrent conversations efficiently.
- Route NLU Notifications: Configure message routing so notifications flow to multiple portals as needed.
For administrators, this feature offers enhanced control and security over Virtual Agent interactions across multiple portals, improving user experience by maintaining conversation relevance and confidentiality without technical overhead.
Virtual Agent features the ability to have multiple conversations at the same time, separated and directed by chosen context.
Overview of Multiple active conversations for Virtual Agent
Virtual Agent messages commonly follow one conversation with a shared history that persists on all VA clients, and thus all portals. For example, if you’re conversing with Virtual Agent in a Service Portal (SP) portal context, the same conversation is shown in an Employee Service Center (ESC) portal. The multiple active conversations feature expands the reach of Virtual Agent by eliminating the one-conversation limit. By configuring their Virtual Agent conversations based on context, customers can choose to share or restrict any or all content between concurrent conversations on differing portals.
Each Virtual Agent conversation is fully independent, with no overlap between chats. For example, a conversation in SP will be entirely different from ESC. Each conversation also has its own transcript. You must set up context values for Natural Language Understanding (NLU) chats, while Large Language Model (LLM) chats are automatically configured for multiple active conversations based on each portal. An administrator can activate an LLM assistant for each portal by using guided setup configurations. (For more information on configuring Virtual Agent conversations, see Conversational Interfaces Guided Setup.)
Benefits of multiple active conversations
Previously, if a user was engaged in a conversation with a virtual agent, the chat would take place in a single context. Switching contexts involved a risk of exposing sensitive information by carrying over the entire chat history to the other portal. For example, if you have an HR conversation in the HR portal, then brought up an IT request, the chat continues in the IT portal. However, this request also brings the HR conversation history into the IT portal with it. Alternatively, admins can activate the skip_load_history system parameter to avoid exposure risk, but the initial conversation closes when the chat continues on the IT portal.
To exclude conversation history between portals, use the following procedure:
- Navigate to .
- Select the Agent Chat Configuration for which you want to set the context value.
- In the Server Script window, add the line skip_load_history: true to load conversations without the conversation history.
The multiple active conversations feature bypasses the skip_load_history method, and enables continuous engagement with Virtual Agent chat, by routing selected notifications and topics to their configured contexts only. Users don’t need scripting or extensive customization, and they can conduct conversations without interruption or information exposure in the wrong context. With portals and notification contexts aligned, users receive information appropriate to their context, including incident updates and other relevant data.
Considerations for using multiple active conversations
Implementing multiple active conversations should happen in the following order: Admins should define portal consumer context values, set or update a default context, activate the multiple active conversations system, and finally, configure notifications sent to portals. However, if the delivered Service Portal context is sufficient, admins can skip configuring and setting values.
Topics can be created within a portal context. If the portal context maps to consumer account context, then topics map to consumer account contexts.