Documentation Index
Fetch the complete documentation index at: https://docs.serval.com/llms.txt
Use this file to discover all available pages before exploring further.
About ServiceNow
ServiceNow is an IT service management (ITSM) platform that manages tickets, incidents, change requests, and IT assets.What the ServiceNow integration enables
| Capability | Description |
|---|---|
| Ticket Sync | Native bidirectional sync between Serval tickets and ServiceNow incidents |
| Service Catalog | Sync and order ServiceNow catalog items directly through Serval workflows |
| Knowledge Base | Sync knowledge articles from ServiceNow directly into Serval for AI-powered assistance |
| Workflow Automation | Build Serval workflows for incidents, problems, changes, catalog ordering, and more using ServiceNow APIs |
| Access Profiles | Sync ServiceNow groups, roles, departments, companies, and locations for access control and provisioning |
ServiceNow Configuration
Prerequisites
Before configuring the ServiceNow integration in Serval, ensure you have:- Access to your ServiceNow instance as an administrator
- Permissions to create users, roles, and ACLs (and OAuth application records if using OAuth)
- Knowledge of your ServiceNow instance name
- A decision on authentication method (see below)
Authentication: OAuth 2.0 (recommended) or Basic
Serval supports two ways to authenticate to your instance’s REST APIs:| Method | What you enter in Serval | Notes |
|---|---|---|
| OAuth 2.0 (Client Credentials) | Instance name, Client ID, Client Secret | Recommended. Serval obtains short-lived bearer tokens from https://<instance>.service-now.com/oauth_token.do. |
| Basic authentication | Instance name, Username, Password | Uses HTTP Basic auth with a ServiceNow user account. Use when inbound OAuth client credentials are not available or not yet configured. |
Step 1: Create a Dedicated Integration User
Navigate to User Administration
- Log in to your ServiceNow instance as an administrator
- In the application navigator search bar, type “Users” and select User Administration → Users
- Click New to create a new user
Configure User Details
| Field | Value |
|---|---|
| User ID | serval.integration |
| First name | Serval |
| Last name | Integration |
| Active | ✅ Checked |
| Web service access only | ✅ Checked (recommended for API-only accounts) |
| Internal Integration User | ✅ Checked (if available in your ServiceNow version) |
| Photo (Optional) | Download the Serval logo then select it from your downloads |
Set the user password (Basic authentication only)
- On the Users page, search for the user you just created and click on it
- Click Set Password
- Click Generate Password
- Important: Click the Copy button to copy the password and save it securely
- Click Submit
Step 2: Create a Custom Role for Serval
itil or admin.Create the Custom Role
- In the navigator, search for “Roles” and select User Administration → Roles
- Click New
- Fill in the role details:
| Field | Value |
|---|---|
| Name | x_serval_integration |
| Description | Custom role for Serval integration with least-privilege API access |
- Click Submit
Add Base Roles
| Role | Purpose |
|---|---|
rest_api_explorer | Enables REST API access |
personalize_choices | Allows reading sys_choice values |
personalize_dictionary | Allows reading sys_dictionary for field definitions |
Step 3: Configure Table Access via ACLs
Serval requires specific read/write access to various ServiceNow tables. You’ll create Access Control List (ACL) rules to grant only the necessary permissions.- Table API (
/api/now/table) — Active by default on all instances - Service Catalog API (
/api/sn_sc/servicecatalog) — Requires the Service Catalog plugin (active by default) - Change Management REST API (
/api/sn_chg_rest/change) — Requires the Change Management - REST API plugin (com.snc.change_management.rest_api) - Attachment API (
/api/now/attachment) — Active by default on all instances
- Required Table Access
- Create ACLs
- Alternative: Use OOB Roles
Incident Management Tables
| Table | Read | Create | Write | Purpose |
|---|---|---|---|---|
incident | ✅ | ✅ | ✅ | Incident records (all standard fields) |
sys_journal_field | ✅ | ❌ | ❌ | Comments and work notes |
Service Catalog Tables
| Table | Read | Create | Write | Purpose |
|---|---|---|---|---|
sc_cat_item | ✅ | ❌ | ❌ | Catalog item details |
sc_category | ✅ | ❌ | ❌ | Catalog categories |
sc_request | ✅ | ✅ | ❌ | Service requests |
sc_req_item | ✅ | ✅ | ✅ | Requested items |
item_option_new | ✅ | ❌ | ❌ | Catalog item variable definitions |
io_set_item | ✅ | ❌ | ❌ | Variable set to catalog item mapping |
question_choice | ✅ | ❌ | ❌ | Choices for select-type catalog variables |
sys_attachment | ❌ | ✅ | ❌ | File attachment uploads for requested items |
Configuration Tables (Read-Only)
| Table | Read | Create | Write | Purpose |
|---|---|---|---|---|
sys_user | ✅ | ❌ | ❌ | User lookup for assignment |
sys_user_group | ✅ | ❌ | ❌ | Assignment group lookup |
sys_choice | ✅ | ❌ | ❌ | Field dropdown values |
sys_dictionary | ✅ | ❌ | ❌ | Field definitions |
cmdb_ci_service | ✅ | ❌ | ❌ | Business services |
Knowledge Base Tables (Read-Only)
| Table | Read | Create | Write | Purpose |
|---|---|---|---|---|
kb_knowledge_base | ✅ | ❌ | ❌ | Knowledge base metadata |
kb_category | ✅ | ❌ | ❌ | Knowledge categories |
kb_knowledge | ✅ | ❌ | ❌ | Knowledge articles |
User Criteria Tables (Read-Only)
These tables are used to determine which users have access to knowledge articles and catalog items.| Table | Read | Create | Write | Purpose |
|---|---|---|---|---|
user_criteria | ✅ | ❌ | ❌ | User criteria definitions (users, groups, companies, etc.) |
kb_uc_can_read_mtom | ✅ | ❌ | ❌ | Knowledge article access - users who CAN read |
kb_uc_cannot_read_mtom | ✅ | ❌ | ❌ | Knowledge article access - users who CANNOT read |
sc_cat_item_user_criteria_mtom | ✅ | ❌ | ❌ | Catalog item access - users who CAN access |
sc_cat_item_user_criteria_no_mtom | ✅ | ❌ | ❌ | Catalog item access - users who CANNOT access |
Change Management Tables
These tables are required for change request workflows.| Table | Read | Create | Write | Purpose |
|---|---|---|---|---|
change_request | ✅ | ✅ | ✅ | Change request records |
sysapproval_approver | ✅ | ❌ | ✅ | Change request approval records |
/api/sn_chg_rest/change), which requires the Change Management - REST API plugin to be active on your ServiceNow instance. This plugin is active by default on most instances.Problem Management Tables
| Table | Read | Create | Write | Purpose |
|---|---|---|---|---|
problem | ✅ | ✅ | ✅ | Problem records |
Access Management & Resource Sync Tables
These tables are required if using Serval’s access profile capabilities for syncing organizational resources and provisioning/deprovisioning users.sys_user and sys_user_group tables listed above under Configuration Tables still require read access for basic functionality regardless.| Table | Read | Create | Write | Delete | Purpose |
|---|---|---|---|---|---|
sys_user | — | ❌ | ✅ | ❌ | Write access for department assignment (read access already listed above) |
sys_user_grmember | ✅ | ✅ | ❌ | ✅ | Group membership provisioning and deprovisioning |
sys_user_role | ✅ | ❌ | ❌ | ❌ | Role definitions for resource sync |
sys_user_has_role | ✅ | ✅ | ❌ | ✅ | Role assignment provisioning and deprovisioning |
core_company | ✅ | ❌ | ❌ | ❌ | Company records for resource sync |
cmn_department | ✅ | ❌ | ❌ | ❌ | Department records for resource sync |
cmn_location | ✅ | ❌ | ❌ | ❌ | Location records for resource sync |
cmn_cost_center | ✅ | ❌ | ❌ | ❌ | Cost center records for resource sync |
Step 4: Assign the Custom Role to the Integration User
Open the User Record
- Navigate to User Administration → Users
- Find and open the
serval.integrationuser
Step 5: OAuth Application Setup (OAuth 2.0 only)
Skip this step if you use Basic authentication.Enable inbound client credentials (system property)
- In the navigator, type
sys_properties.listand press Enter to open the System Properties table - Search for
glide.oauth.inbound.client.credential.grant_type.enabled - If the property does not exist, click New and create it:
| Field | Value | |
|---|---|---|
| Name | glide.oauth.inbound.client.credential.grant_type.enabled | |
| Type | `true | false` |
| Value | true | |
| Application | Global |
- If the property already exists but is set to
false, change it totrue - Click Submit / Update
Create an OAuth application
- Log in as an administrator
- Open System OAuth → Application Registry
- Click New. ServiceNow shows a list of OAuth application types — pick the one for inbound access (external systems calling into your instance). Do not choose Connect to a third party OAuth Provider or other outbound options; those are for ServiceNow calling external OAuth servers, not for Serval.
-
Recommended: New Inbound Integration Experience — current UI for inbound OAuth (including client credentials). Use this when it appears in the list.
When the wizard asks Select your application connection type, choose OAuth - Client credentials grant (machine-to-machine; this matches how Serval calls
oauth_token.do). Do not choose Authorization code, JWT bearer, Resource owner password, or third-party ID token flows for the Serval integration.

-
Alternative: [Deprecated UI] Create an OAuth API endpoint for external clients — older wizard for the same kind of inbound app Serval uses. “Deprecated UI” refers to ServiceNow replacing the screen flow, not to Serval rejecting the credentials. It can still work and still produces Client ID / Client Secret and
oauth_token.doclient-credentials tokens. Some teams see odd default forms (for example, OAuth Application User hidden until you change Form layout); trying New Inbound Integration Experience instead often avoids that. -
Complete the wizard or form and give the application a clear name (for example,
Serval integration). Follow prompts to associate your integration user if the flow asks for it — wording depends on your release; align with ServiceNow’s inbound OAuth documentation if steps differ slightly.
Enable client credentials and link the integration user
-
Set Client type to run API calls as your integration account — for example Integration as a User (wording varies by release). That tells ServiceNow which
sys_usersupplies roles, ACLs, and audit fields (sys_created_by/sys_updated_by) for requests made with a client-credentials token. - Allow the Client credentials grant. Often this is not on the main form: open the OAuth Entity or OAuth Entity Profile related list on the same Application Registry record, open the related row, and confirm Client credentials is enabled. Save that record if you changed it.
-
Set OAuth Application User to your integration user (for example
serval.integration). Serval needs this so issued tokens act as that user. If you do not see an “OAuth Application User” (or similar) field on the form, ServiceNow frequently hides it on the default layout. Add it explicitly:- On the Application Registry record, open the header context menu (⋮) → Configure → Form layout — or use Personalize / Form design if that is what your UI offers.
- Move OAuth Application User from Available to Selected, save the layout, then reload the form. The field should appear so you can select your integration user.
- List view: Switch Application Registry to the list layout; OAuth Application User may appear as a column you can set inline (community-reported on newer releases).
- Related profile: On a few releases, the user reference lives on the OAuth Entity Profile row — open it from the related list and look for an application or integration user field.
- Click Update / Save on the Application Registry record.
Integration user does not appear in the OAuth Application User lookup
Integration user does not appear in the OAuth Application User lookup
- Ensure the user has First name and Last name populated. On some releases, users without both names are omitted from the inbound OAuth user picker.
- Confirm the user is Active and matches any Identity type or integration-user rules your instance enforces.
- If the field never appears even after form layout changes, try the list view on Application Registry or ask a ServiceNow admin to verify UI policies on the Application Registry / OAuth tables. ServiceNow also documents adding an OAuth application user under Platform security → Authentication in the product docs (search for add OAuth application user in ServiceNow Docs).
Serval or proxy logs show OAuth `access_denied` / `server_error` (401)
Serval or proxy logs show OAuth `access_denied` / `server_error` (401)
https://<instance>.service-now.com/oauth_token.do. If ServiceNow responds with {"error":"server_error","error_description":"access_denied"} (often surfaced in logs as oauth2: "server_error" "access_denied"), the token was rejected by ServiceNow, not by Serval’s storage. A log line that mentions decrypting the integration secret may still be wrapping this same OAuth failure.Work through these on the ServiceNow side:- Inbound client credentials enabled — Verify you completed the Enable inbound client credentials step earlier in this guide. The system property
glide.oauth.inbound.client.credential.grant_type.enabledmust betruein Global scope. This is the most common cause ofaccess_denied. - OAuth application user — The inbound application must be tied to your integration user (for example via OAuth Application User on the Application Registry record, or the equivalent in the new inbound wizard). That user must be Active and have the roles/ACLs from this guide.
- Client credentials grant — On the OAuth Entity / OAuth Entity Profile related to the application, Client credentials must be allowed.
- Client ID and Client Secret — Copy again from ServiceNow into Serval with no leading/trailing spaces. If you rotated the secret in ServiceNow, update the connection in Serval.
- Auth Scopes (related list) — Serval requests a token without a
scopeparameter. If you added rows under Auth Scopes on the OAuth application, your instance may require a matching scope on the token request; try clearing optional scopes on the app so the default behavior matches Serval, or ask your ServiceNow admin.
--data-urlencode so special characters in the client secret are percent-encoded correctly:access_denied, fix the OAuth application configuration until you receive an access_token, then retry Serval.Step 6: Identify Your ServiceNow Instance
Your ServiceNow instance name can be found in your ServiceNow URL:- If your ServiceNow URL is
https://mycompany.service-now.com, then:- Instance Name:
mycompany
- Instance Name:
Step 7: Configure the Integration in Serval
Once you have completed the ServiceNow setup (user, roles, ACLs, and OAuth application if applicable), connect Serval:Navigate to ServiceNow App
- In Serval, go to Apps → Available → ServiceNow → Connect
- The ServiceNow configuration form will appear
Enter configuration details
- OAuth 2.0 (recommended)
- Basic authentication
| Field | Description | Example |
|---|---|---|
| Instance Name | Subdomain of your instance (https://**mycompany**.service-now.com) | mycompany |
| Authentication method | OAuth 2.0 (Client Credentials) | — |
| Client ID | From System OAuth → Application Registry | (from ServiceNow) |
| Client Secret | From the same OAuth application | (from ServiceNow) |
Real-Time Comment Sync via Webhook (Optional)
By default, Serval polls your ServiceNow instance to sync comments. For faster, near-instant comment delivery, you can configure a Business Rule that pushes new comments to Serval via webhook. This applies to comments on Incidents and Catalog Request Items that were created by the Serval integration.sys_journal_field table. No ServiceNow plugins, store apps, or additional licensing are required.How it works
When a comment is added to a Serval-managed record, an async insert Business Rule fires on thesys_journal_field table. The rule verifies the parent record was opened by the Serval service account, constructs a JSON payload, and sends it asynchronously to the Serval webhook. Serval processes the event and delivers the comment to the relevant conversation in real time.
Webhook endpoint
| Property | Value |
|---|---|
| URL | https://svwebhook.api.serval.com/servicenow/new-comment |
| Method | POST |
| Content-Type | application/json |
| Authentication | Token via X-Serval-Webhook-Token header |
Expected payload schema
Expected payload schema
| Field | Type | Description |
|---|---|---|
instance_url | string | Your ServiceNow instance URL |
table | string | Source table: incident, sn_hr_core_case, or sc_req_item |
record_sys_id | string | sys_id of the parent record |
number | string | Record number, e.g. INC0012345, HRC0001234, RITM0056789 |
comment.sys_id | string | sys_id of the journal entry |
comment.element | string | comments or work_notes |
comment.value | string | The comment body text |
comment.sys_created_by | string | user_name of the commenter |
comment.sys_created_on | string | ServiceNow timestamp |
Create the Business Rule
Configure the rule settings
| Field | Value |
|---|---|
| Name | Serval – Sync Comment to Webhook |
| Table | sys_journal_field |
| Advanced | Checked |
| When | async |
| Insert | Checked |
| Update | Unchecked |
| Delete | Unchecked |
| Query | Unchecked |

Live Agent Handoff via VA Bot-to-Bot (Optional)
Serval can hand a conversation off to a human ServiceNow agent mid-flow, then bridge the agent’s replies back into the Serval ticket so the user keeps chatting in their original surface (Slack, Teams, web, etc.). This rides on ServiceNow’s native Virtual Agent Bot-to-Bot APIs — there is no Serval-shipped update set and no Scripted REST API to install on your instance. Setup on the SNOW side is roughly: install the Virtual Agent API plugin (if not already installed), grant the Serval service account a few additional permissions, create a Token Verification + Message Auth + Provider Application + Outbound REST Message pointing at a Serval-hosted webhook URL, and (optionally) enable the AWA routing for the chat channel you want to use for the handoff.subtype = "interaction" on the existing ServiceNow integration — they do not create a separate integration or channel type. The auto-created interaction record on the SNOW side is the same record type SNOW uses for all VA-mediated chats.How the bridge works
The bridge uses three endpoints on SNOW’s side:POST /api/sn_va_as_service/bot/integration(SNOW inbound) — Serval calls this to open, send messages on, and end a Bot-to-Bot conversation. The action discriminator is in the body (action: "START_CONVERSATION" | "AGENT_CHAT" | "END_CONVERSATION").- Outbound REST Message (SNOW outbound) — when the live agent types a reply, SNOW’s Provider Application looks up its associated Outbound REST Message and POSTs the response to the URL you configured there. That URL is the Serval-hosted webhook.
/api/now/table/awa_agent_presence_capacity(SNOW inbound, optional) — Serval calls this fromservicenow.checkLiveAgentAvailabilityas a pre-flight to know whether any agents are currently online.
channelIdonstartLiveAgentSession— maps to a SNOWsys_cs_channelrecord. Defaults to"chat". The channel record’s “Bot to Bot Synchronous” flag and its AWA queue assignment together determine where the conversation routes.contextVariablesonstartLiveAgentSession— a free-form key/value bag passed to SNOW ascontextVariableson every turn. Customers configure their AWA routing rule against the variable name(s) of their choice (e.g.u_liveagent_optional_skills). See Step 5 below.
Prerequisites
- Virtual Agent + Virtual Agent API plugins installed on your ServiceNow instance (Quebec or later).
- The Serval ServiceNow integration must already be connected (Steps 1–7 above).
- Now Assist Pro licensing is not required — Bot-to-Bot is part of the base Virtual Agent API plugin.
Limitations (read before you commit)
- Closing a Serval ticket does not automatically end the SNOW conversation. Your workflow should call
servicenow.endLiveAgentSession({...})when the ticket resolves if you want symmetric cleanup. The conversation eventually times out on the SNOW side either way. - The agent’s identity is not in the live message stream. SNOW’s Bot-to-Bot response payloads carry the agent’s typed text (
uiType: "OutputText") but not the human agent’ssys_userreference. If you need to render “Agent Jane Doe joined” in the user’s surface, poll the auto-createdinteractionrecord’sassigned_tofield from a workflow — see the Optional: post-START agent-identity poll example below. - Inbound auth verification is currently advisory. The Basic-auth password on inbound webhooks is forwarded onto the event for downstream verification, but the constant-time check against the rotated token is not yet enforced server-side. The per-install webhook URL contains an unguessable UUID, which is the practical access control today. Treat the rotated token as a not-yet-load-bearing secret in the meantime — full server-side verification is on the roadmap.
- Attachments do not yet cross the bridge. Files attached on either side are not synced through Bot-to-Bot. Plain text only.
Step 1: Grant additional permissions to the Serval service account
The standard Serval ACLs cover the Table API surface used by the rest of the integration. Live Agent needs two additional reads on AWA tables and theinteraction table, plus two SNOW roles. Add these to your Serval service-account user:
Roles:
| Role | Why |
|---|---|
virtual_agent_admin | Required by the Bot-to-Bot endpoint (/api/sn_va_as_service/bot/integration) for the bot-management Scripted REST API to accept the call. |
interaction_agent | Lets Serval read the auto-created interaction record after START_CONVERSATION (for the optional post-START agent-identity poll) and is required for any future attachment-transfer support. |
Type: record, Operation: read, Requires role: x_serval_integration or whichever role you assigned to the Serval service account):
| Table | Purpose |
|---|---|
awa_agent_presence_capacity | Used by checkLiveAgentAvailability. Without this, the action will return agentsAvailable: false for everyone. |
awa_agent_presence | Used by AWA routing — presence_capacity is a view that joins this in. |
awa_agent_capacity | Same; joined by the presence_capacity view. |
interaction | Read access for the optional assigned_to poll. Already covered if you’re using the interaction_agent role above. |
Step 2: Generate the shared bot token in Serval
In your Serval workspace, navigate to App Instances → ServiceNow → Ticket Sync settings. Scroll to the Live Agent (VA Bot-to-Bot) section and click Generate Token. You’ll see three values you’ll need in the next step:| Value | What it is |
|---|---|
| Inbound Webhook URL | Serval-hosted URL the SNOW Outbound REST Message will POST agent replies to. Per-install — contains an unguessable UUID — so do not share between environments. |
| Authentication Username | Always the literal string serval. |
| Authentication Token | One-time-displayed opaque secret — copy it now, you cannot view it again. Click Rotate Token later if you ever need a new one (rotation invalidates the previous value). |
- The Token Verification record. Serval injects this value into
body.tokenon every/api/sn_va_as_service/bot/integrationcall; SNOW’s Message Auth middleware verifies it before processing. - The Outbound REST Message Basic-auth password. SNOW presents this value when posting agent replies to the Inbound Webhook URL above.
Step 3: Configure the four SNOW records that wire up Bot-to-Bot
SNOW’s Bot-to-Bot setup links four records together. The record names below are the OOB tables — the navigation labels may vary slightly by release.Enable inbound auth on the VA Bot Integration Scripted REST API
Create the Token Verification record
token_verification.list and press Enter. Click New. Fill in:| Field | Value |
|---|---|
| Name | Serval (or any human-readable name) |
| Token | The Authentication Token from Serval (from Step 2) |
body.token on every inbound call from Serval.Create the Message Auth record
message_auth.list and press Enter. Click New. Fill in:| Field | Value |
|---|---|
| Name | Serval Bot Auth |
| Provider | Serval (free-text; only used for organization) |
| Inbound Message Verification | Pick the Token Verification record from the previous step (Serval) |
| Outbound Message Creation | Pick the same Token Verification record |
Create the Provider Application
sys_cs_provider_application.list and press Enter. Click New. Fill in:| Field | Value |
|---|---|
| Name | Serval Bot |
| Inbound ID | serval (or any unique slug — this is the appInboundId value, only needed in multi-bot instances; single-bot instances can pick any value) |
| Message Auth | Pick the Message Auth record from the previous step (Serval Bot Auth) |
| Provider | VA Bot to Bot Provider |
Create the Outbound REST Message
REST Message and open the table. Click New. Fill in:| Field | Value |
|---|---|
| Name | Must exactly match the Provider Application name from the previous step (Serval Bot). SNOW finds the outbound endpoint by name lookup against the active Provider Application. |
| Endpoint | The Inbound Webhook URL from Serval (Step 2). |
| Authentication type | Basic |
| Use mutual authentication | unchecked |
| Basic auth profile | Create a new Basic Auth profile (or pick an existing one) with Username: serval and Password: <Authentication Token from Step 2>. |
post with:| Field | Value |
|---|---|
| HTTP method | POST |
| Endpoint | Same as the parent REST Message |
| HTTP Headers | Content-Type: application/json |
Verify the chat channel is Bot-to-Bot enabled
sys_cs_channel.list and press Enter. Find the channel you intend to route through (the OOB one is named chat — its sys_id is what you’ll pass as channelId from your workflows; the literal string "chat" also works on most releases).On the channel record, confirm Bot to Bot Synchronous = true. If it’s not, set it and save. Without this flag, the bot integration endpoint will reject START_CONVERSATION calls with a routing error.- The Token Verification record’s
Tokenfield. - The Basic Auth profile used by the Outbound REST Message (or, if you embedded the password directly on the REST Message, update it there).
Step 4: SDK building blocks
The SDK exposes four thin building-block actions. They are intentionally not orchestration helpers — live-agent flows vary enough between customer SNOW configurations (different chat experiences, custom AWA routing rules, renamed topics, varying trigger phrases for NLU) that workflow authors should compose these directly rather than configure a single high-level wrapper.Step 5: Customize routing with context variables
contextVariables is the principal knob for AWA routing. The variable names you pass are customer-specific — they must match the conditions on whichever AWA routing rule you’ve configured on your SNOW instance.
For example, GM’s “IT Live Agent Chat” queue is configured with the condition context.u_liveagent_optional_skills = IT. So a Serval workflow targeting that queue passes:
u_skill_required, routing_skill, or any other u_-prefixed (or unprefixed) custom variable name. To find the right variable name on your instance, check your AWA routing rule’s condition script, or ask your SNOW admin.
Custom interaction-record fields (e.g. CMDB tag, custom assignment_group overrides, region routing) can also be projected on top of the auto-created interaction record via a SNOW-side Business Rule that reads our contextVariables payload. This is a pure SNOW-side customization — no Serval changes required.
Step 6: Example workflow — START_CONVERSATION with routing + agent-identity poll
This mirrors the canonical pattern verified end-to-end against a real ServiceNow instance. You can drop this into a Serval workflow as a starting point and adapt the routing skills, trigger phrase, and message composition to your environment.
- User → agent: any new message the user sends in their original surface fans out to the SNOW agent automatically as an
AGENT_CHATturn — no extra workflow code required (this is whatservicenowInteractionEgresseron the Serval backend does). - Agent → user: SNOW’s Outbound REST Message posts the agent’s typed reply to the Inbound Webhook URL configured in Step 3. Serval ingresses it as a comment on the bridged ticket, which surfaces back in the user’s original surface.
Step 7: Optionally end the session symmetrically
When the Serval ticket auto-resolves or the user abandons:END_CONVERSATION cleans up the interaction record faster and gives the agent a clean “user ended chat” signal.


