push connector · incident table / em

Wytness for ServiceNow

Every anomaly becomes an incident in the queue your team already triages — or an ITOM event if you run Event Management.

what it does

Where your alerts land

Wytness creates one incident per anomaly through your instance's REST Table API — available on every instance, with no GRC or ITOM EM licence required. If you do have Event Management, opt in with one config field and Wytness sends through the ITOM jsonv2 surface instead, flowing through your correlation engine before becoming alerts.

setup

From nothing to first delivery

Create a dedicated integration user on your instance with rights to insert into the Incident table (the `itil` role covers it), or into Event Management if you choose the EM path.

In the Wytness app, go to Integrations → Connectors → Add connection → ServiceNow and enter the instance URL (`https://<instance>.service-now.com`), the integration username, and the password. The delivery URL is derived for you from the endpoint kind.

Pick the endpoint kind: Incident Table (default, every instance) or ITOM Event Management (requires the paid ITOM EM SKU).

Click Test connection. A Wytness test record should appear in your Incident list within seconds, deduped via the `u_wytness_event_id` field.

Save. Anomalies dispatch within about 30 seconds of detection.

the payload

What arrives in your incident queue

Severity maps conservatively so your assignment rules can re-tune it: critical → impact/urgency 1, high → 2, medium and low → 3. The u_wytness_* fields carry the full alert identity once you create those columns (stock instances silently drop unknown fields); the description always embeds the View-in-Wytness link with the alert ID, no schema prep needed.

servicenow_incident.json

1{
2  "short_description":     "[Wytness] off_hours_activity on payments-reconciler-v3",
3  "description":           "Tool invocation outside business hours window (08:00-18:00 AEST).\n\nView in Wytness: https://app.wytness.ai/anomalies?alert_id=9f2d1c34-8a7b-4e2d-b1a0-5c6d7e8f9a0b",
4  "impact":                "2",
5  "urgency":               "2",
6  "category":              "wytness_anomaly",
7  "u_wytness_event_id":    "9f2d1c34-8a7b-4e2d-b1a0-5c6d7e8f9a0b",
8  "u_wytness_agent_id":    "payments-reconciler-v3",
9  "u_wytness_rule":        "off_hours_activity",
10  "u_wytness_severity":    "high",
11  "u_wytness_detected_at": "2026-05-23T14:23:41.182Z",
12  "u_wytness_url":         "https://app.wytness.ai/anomalies?alert_id=9f2d1c34-8a7b-4e2d-b1a0-5c6d7e8f9a0b"
13}

prove it landed

Verify end to end

The wizard's Test connection creates a real incident before you save. To confirm from your side:

verify.sh

1# After the wizard's Test connection, list the newest Wytness incidents
2# over the Table API (same surface Wytness writes through). Query by the
3# short-description prefix — it works on a stock instance with no schema prep:
4$ curl -su '<integration-user>:<password>' \
5    "https://<instance>.service-now.com/api/now/table/incident?sysparm_query=short_descriptionLIKE[Wytness]^ORDERBYDESCsys_created_on&sysparm_limit=5" \
6    | jq '.result[].short_description'

the boundary

What flows and what doesn't

Writes

One incident per Wytness anomaly. Severity → impact/urgency mapped conservatively (`critical → 1`, `high → 2`, `medium`/`low → 3`).

Dedupe

`u_wytness_event_id` carries the Wytness `alert_id` once you add that column (stock instances drop unknown fields); the description always embeds the alert link either way.

Reads

Nothing. We don't query your existing tables.

Modifies

Nothing else. No workflows, dashboards, or other tables touched.

Network

No change on your side — deliveries are outbound from Wytness to your instance's REST API over HTTPS.

what you need

Required permissions

✓Integration user with the `itil` role (Incident Table writes)
✓Instance URL, username, and password for that user (stored encrypted)
✓For the EM path: the ITOM Event Management SKU and event-write rights

stated plainly

Limitations

—

Custom fields and category

Stock instances silently drop the u_wytness_* fields (unknown columns) and the wytness_anomaly category (an unknown choice value — incidents land as the default category). Create the columns and add the category choice if you want them; the short_description prefix and the description's alert link work with zero schema prep.

—

Routing and assignment

Wytness never sets assignment_group, assigned_to, caller_id, or cmdb_ci — assignment is your policy. Key an assignment rule on the [Wytness] short_description prefix (works stock), or on category / u_wytness_rule / u_wytness_severity after schema prep; templates and SLAs attach like any other source.

—

EM requires ITOM

The Event Management path flows through /api/global/em/jsonv2, which needs the paid ITOM Event Management SKU. The Incident Table path works on every instance.

—

PII pseudonymisation

Anomalies sent to ServiceNow are already pseudonymised on the way in. Your instance sees the same EMAIL_a3f9b1c4 pseudonym shape your auditor sees in the Evidence Pack.

Keep reading

/docs/connectors

Connector setup guide

The full integrator contract — network requirements, delivery semantics, and every wizard field. Read the guide.

/connectors

All connectors

Sentinel, Splunk, ServiceNow, Slack, and the generic webhook. See the index.

tier

Tier availability

Business plan or higher.

Anomalies in the queue your team already triages.

Start recording Ask a question