Service ManagementLive Agent Chat / HandoffLive Agent Message Brokering

Discovery Guide — ServiceNow AWA Live Agent Message Brokering

View as Markdown

Use this guide on a discovery call with a customer to understand their ServiceNow AWA Agent Chat integration setup, as well as their business process around it. This will help you properly configure Moveworks ↔ ServiceNow Live Agent Message Brokering. Message Brokering keeps the handoff inside the same Moveworks chat (no browser redirect) by brokering messages back and forth over the Virtual Agent API.

Overview

  • Same-chat handoff — the user stays in the Moveworks AI Assistant; messages are brokered via API to ServiceNow AWA so the agent sees them in Agent Workspace / Service Operations Workspace.
  • Queues live in ServiceNow — Moveworks does not own routing logic. It passes contextVariables (key-value pairs) to AWA, and ServiceNow’s queue criteria decide where the chat lands.
  • Common out-of-the-box context variables: domain, language, region, queue, mandatory_skills.
    • Custom context variable keys can be added in ServiceNow and used for routing.
  • Auto-translation (DTS / Dynamic Translation Service): with MLS enabled, user → English for the agent. One direction only — agent replies are not translated back into the user’s language.
  • Language default: the language variable is populated from the user’s hr_language attribute, falling back to en.

Prerequisites

  • Virtual Agent API plugin enabled in ServiceNow (typically requires ITSM Pro / Service Operations Workspace).
  • Agent Chat plugin enabled in ServiceNow.

1. ServiceNow Platform Readiness

  1. Do you have the Virtual Agent API plugin enabled? (Typically requires ITSM Pro / Service Operations Workspace.)
  2. Which ServiceNow workspace will agents use — Agent Workspace or Service Operations Workspace?
  3. Is AWA already configured for human-to-human chat today, or is this greenfield?
  4. Which ServiceNow instance(s) are in scope, and on which release family (Washington, Xanadu, Yokohama, etc.)?

2. Queue Strategy (Multiple Queues)

Queues and queue routing definitions live in ServiceNow. Moveworks only passes context to route into them.

  1. How many queues do you have, and what dimensions do they split on? (domain, region, language, business unit, VIP, etc.)
  2. For each queue, what AWA presence / skill criteria does it filter on?
  3. Do you want a default fallback queue if no context matches?
  4. Will any queues be 24/7, or do we need to handle business-hours fallback / out-of-hours messaging?
  5. Should specific intents (HR vs. IT vs. Finance) route to dedicated queues?
  6. Any VIP / executive routing requirements?

3. Context Variables Passed at Handoff

Moveworks supports the out-of-the-box keys, plus custom keys. The key-value pairs must match exactly what each ServiceNow queue expects.

  1. What context variable names does each AWA queue expect? (Field names, not just concepts.)
  2. Specifically — what does your queue use for the skills-based routing field? (Commonly liveagent_optional_skills.)
  3. Should liveagent_optional_skills be populated from the user’s issue domain (HR, IT, Finance) or from another classifier?
  4. Any custom contextVariables beyond domain/language/region? (e.g. employee_type, cost_center, country, priority)
  5. Where should each value be sourced — Moveworks user profile, ServiceNow user record, conversation classification, or static?
  6. Do you need any values normalized/transformed (e.g. “United States” → “US”, “français” → “fr”)?

4. Language & Auto-Translation

The language variable defaults to the user’s hr_language, falling back to en. With MLS enabled, DTS translates user → English for the agent; it does not translate agent → user back into the source language.

  1. Is MLS (Multilingual Support) enabled on your Moveworks instance today?
  2. Which languages are in scope for end users? Do you have a list of official languages your organization supports?
  3. Do you have language-specific queues (e.g., French queue, Japanese queue), or one queue with multilingual agents?
  4. Where does the user’s language come from? (e.g. hr_language on the ServiceNow user record, AD attribute, or self-selected at chat time by the user.)
  5. Is your live agent population English-only? (If not — flag that DTS only translates one direction, so agents must respond in the user’s language or the user reads English.)
  6. Should we auto-route to a native-language queue when one exists, and only fall back to English + DTS when it doesn’t?
  7. Are there regions where this should not be enabled (data residency)?

5. Handoff Timing & Flow

  1. What’s the trigger for handoff — explicit user request (“talk to a person”), failed self-service, sentiment escalation, or a specific intent?
  2. Do you want a pre-handoff form to collect anything (short description, urgency) before queuing?
  3. What wait-time messaging should the user see while queued? Any abandon timeout?
  4. What happens if no agent is available — leave queued, create ticket, or fall back to email?
  5. Should the assistant transcript be attached to the resulting ServiceNow interaction/ticket for the agent’s context?
  6. After the agent ends the chat, what should happen — survey, ticket auto-create, follow-up?

Quick reference — Example context block sent to ServiceNow

1{
2  "contextVariables": {
3    "language": "{{user.hr_language | default: 'en'}}",
4    "liveagent_optional_skills": "{{conversation.domain}}",
5    "region": "{{user.region}}",
6    "domain": "{{conversation.domain}}"
7  }
8}

Each key must match the field name the AWA queue is configured to read.

Sources