Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.neoagent.io/llms.txt

Use this file to discover all available pages before exploring further.

Neo Agent connects to ServiceNow over OAuth 2.0 and emulates webhooks using a Business Rule and System Property — ServiceNow does not have native webhook support like ConnectWise or Halo, so Neo creates these artifacts on your behalf the first time you connect. Once connected, every insert and update on any task-family record — incidents, service requests, request items, catalog tasks, change requests, and problems — is POSTed to Neo’s callback endpoint in real time, where it flows into the same event pipeline as Halo, ConnectWise, and Autotask tickets.

Setup Steps

1. Create the OAuth App

Create an OAuth Application Registry entry in your ServiceNow instance and copy the Client ID and Client Secret.

2. Connect to Neo

Enter your instance URL and OAuth credentials in the Neo dashboard, consent in ServiceNow, and Neo provisions the webhooks automatically.

Webhook Architecture (reference)

Understand the Business Rule and System Property that Neo provisions in your ServiceNow instance, the payload it sends, and how to verify deliveries.

Prerequisites

Before connecting ServiceNow, ensure you have:
  • Admin access to your ServiceNow instance — required to create the OAuth Application Registry entry.
  • A ServiceNow user account that the agent will run as — typically a dedicated service account with the itil role and Table API read/write permissions on the task family. Neo’s writes (notes, state changes, time entries) are attributed to this user in your audit trail. Add the email_api_send role too if you want Neo to be able to send outbound email via SN’s /api/now/v1/email endpoint (the “Email (sent via PSA)” notification mode).
  • A ServiceNow edition with the task table family and OAuth 2.0 enabled (Standard, ITSM, or higher — all current editions qualify).
  • The Neo Agent dashboard at dashboard.neoagent.io.

Supported Ticket Types

Neo treats every record that inherits from ServiceNow’s task parent table as a ticket — agents read, write, search, and trigger workflows on each of the six stock subclasses uniformly:
TypeSN tableNumber prefix
IncidentincidentINC*
Requestsc_requestREQ*
Request Itemsc_req_itemRITM*
Catalog Tasksc_taskTASK*
Change Requestchange_requestCHG*
ProblemproblemPRB*
Workflows can scope to specific types via the Ticket Type filter in the rules-builder (e.g., “fire on incidents and changes only”). Without a filter, a workflow trigger fires across every type.
If your instance uses plugin-gated subclasses (HR Service Delivery, Customer Service Management, Field Service Management, Security Incident, etc.), Neo currently treats those rows as generic tickets via the parent task table. Native enum support for plugin-gated types is filed as a follow-up — let your account team know if you need it prioritized.

Capabilities

The integration covers the full ticket lifecycle on every supported type:
  • Triage — assignment group, urgency, impact, priority, category, subcategory, configuration item
  • Notescomments (customer-facing) and work_notes (internal) journal appends
  • State transitions — open → in-progress → resolved → closed (using the right terminal state per type; change requests close via state=4 to bypass the Change Model)
  • Time entries — written to task_time_worked and attributed to the OAuth user
  • Custom fields — read/write access to any u_* column on the row
  • Webhook triggers — real-time callbacks on insert and update for every task-family subclass

How long does setup take?

Most customers complete connection in under 10 minutes:
  • Creating the OAuth Application Registry entry: ~5 minutes
  • Connecting in the Neo dashboard and consenting: ~2 minutes
  • First sync run (in the background, no action needed): a few minutes depending on instance size
The webhook artifacts (Business Rule + System Property) are created automatically the moment the OAuth flow completes — no manual ServiceNow configuration is required after the OAuth app exists.