Multiple active conversations for Virtual Agent

  • Release version: Yokohama
  • Updated June 24, 2025
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Multiple active conversations for Virtual Agent

    Starting with the Yokohama release, ServiceNow’s Virtual Agent (VA) supports multiple simultaneous conversations, each isolated by context. Previously, chat history was shared across all portals, meaning a conversation in one portal (e.g., Service Portal) was visible in another (e.g., Employee Service Center). The new multiple active conversations feature allows each portal to maintain independent, context-specific conversations with separate transcripts, enhancing privacy and user experience.

    Show full answer Show less

    For Natural Language Understanding (NLU) chats, administrators must configure context values manually. For Large Language Model (LLM) chats, multiple active conversations are automatically enabled per portal. Administrators can activate LLM assistants for each portal through guided setup tools.

    Benefits

    • Contextual separation: Conversations do not overlap across portals, preventing sensitive information exposure.
    • Improved user experience: Users can engage in different conversations simultaneously without losing chat history or switching contexts awkwardly.
    • No scripting required: Eliminates the need for custom scripting previously required to avoid sharing chat history between portals.
    • Targeted notifications: Relevant notifications and updates are routed only to the appropriate portal context, ensuring users receive pertinent information.

    Implementation Guidance

    • Define portal consumer context values and set or update a default context before activating the multiple active conversations feature.
    • Activate the multiple active conversations system to enable concurrent, isolated chats.
    • Configure notification routing so Virtual Agent messages and alerts are delivered to the correct portal contexts.
    • If the default Service Portal context suffices, some configuration steps can be skipped.

    Managing Conversation History

    Previously, administrators used the skiploadhistory parameter to prevent chat history from carrying over between portals, but this interrupted conversations. The multiple active conversations feature replaces this by handling chat routing natively, maintaining continuous conversations without exposing prior chat content across portals.

    Practical Impact for ServiceNow Customers

    This enhancement allows organizations to deploy Virtual Agent across multiple portals, such as HR and IT, with confidence that conversations remain secure and contextually relevant. It simplifies management by reducing the need for custom scripts and improves end-user engagement by supporting multiple distinct interactions simultaneously.

    As of the Yokohama release, Virtual Agent (VA) 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:

    1. Navigate to All > Service Portal > Agent Chat.
    2. Select the Agent Chat Configuration for which you want to set the context value.
    3. In the Server Script window, add the line skip_load_history: true to load conversations without the conversation history.
    Note:
    The script syntax may differ depending on the configuration.

    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.