Skip to main content
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: A ticket’s contact, the person Neo’s client-facing notes and notifications go to, is the Caller on an incident. On a request, request item or catalog task it is the Requested for user of the request it belongs to. 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
  • Notes — comments (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. A custom field condition in a ticket filter names the column, such as u_asset_tag; Neo also reads asset_tag as u_asset_tag and ignores case. Neo checks the name against the columns of an incident it can read. When the name matches no column, the run stops and your Inbox names the column, because ServiceNow would ignore that condition and return every ticket. When Neo can read no incident, the filter matches no ticket
  • Webhook triggers — real-time callbacks on insert and update for every task-family subclass
On the agent’s Tickets permission group, the Fields selector limits which ticket fields an update may change, such as State, Assignment Group or Assigned To. The ServiceNow sections of PSA API list every option and what the list does not limit.

​
Dependent choice lists

ServiceNow can make one choice field depend on another: each sys_choice row names its parent in the dependent_value column, and only that parent’s children are valid. incident.subcategory depends on incident.category this way. Triage reads that column. When it picks a subcategory, the options are narrowed to the subcategories configured under the category in effect for that run — the one triage just chose, or the one already on the ticket. A subcategory belonging to a different category is then not among them, and one already on the ticket that the narrowed list does not carry is replaced whenever the model names a replacement. The narrowing needs a category to scope by. When the ticket has none and the run does not set one, or when your instance has no subcategory configured under that category, triage offers the full subcategory list rather than an empty one, and the pair it writes is only as good as the model’s reading of the ticket. Enable Category in the same Ticket Triage action so the run has a category to scope by.
ServiceNow’s Table API accepts a category/subcategory pair that its own configuration forbids, because dependent_value drives the UI picker rather than API validation. So the option list is the only place this can be enforced.
This reads your instance live, so a dependent choice list you add or re-parent later is picked up with no configuration in Neo.

​
Business Rules that abort a change

A Business Rule on your instance can abort a change, for example one that blocks Assignment Group changes on some tickets. ServiceNow then writes nothing from that request. The agent is told not to retry it and to go on with the rest of the run, and the run log names the rule that blocked the change. To let Neo make that change, edit the rule’s conditions in ServiceNow (System Definition → Business Rules).

​
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.