ServiceNow (Two-Way)

ServiceNow sends incident webhooks to JAMS Incident Management, and JAMS calls / SMS-es / pushes your on-call team until someone responds. When they Acknowledge or Resolve, JAMS writes the new state back into the ServiceNow incident — so the ITSM record, assignment, and any downstream automation all reflect the resolution without anyone double-bookkeeping. ServiceNow records the work; JAMS makes sure a human actually picks up.

Plan availability: The ServiceNow integration is included on the Professional plan and up. See Plans & Billing.

Two directions. This page covers ServiceNow → JAMS (a ServiceNow incident pages your on-call team). JAMS can also go the other way and open a brand-new ServiceNow incident from any other alert — see Open a ServiceNow incident from a JAMS alert near the bottom.

What you'll get

After setup:

A ServiceNow incident (e.g. Priority 1) is created → a Business Rule POSTs to JAMS's webhook → recipients get a call (and/or SMS/push/email/Teams/Slack per your flow)
Recipients press 1 to Acknowledge or 2 to Resolve — or do nothing and escalation continues to the next person
Acknowledge sets the ServiceNow incident to In Progress; Resolve sets it to Resolved (with a close code + note)
A work note is added to the incident recording who acted and how (voice, SMS, etc.)
If the incident is Resolved or Closed directly in ServiceNow, JAMS stops escalating automatically
The /incidents page shows everything in flight with one-click Acknowledge / Resolve buttons

What you'll need

A ServiceNow instance (a free Personal Developer Instance works for testing).
A ServiceNow integration user with permission to read and update the Incident table (the itil role is sufficient). Basic auth with this user is the fastest way to start; OAuth 2.0 is the production-grade option.
Admin access in ServiceNow to create a Business Rule (or a Flow Designer flow) on the Incident table.

Step 1 — Create the ServiceNow connection in JAMS

The connection bundles your instance credentials, the recipients, the escalation policy, and the per-flow webhook URL.

In JAMS, open Integrations → ServiceNow from the sidebar.
Click Create a ServiceNow Connection and fill in:
- Connection name — anything memorable (e.g. prod-itsm).
- Instance URL — your full instance base URL, e.g. https://dev12345.service-now.com.
- Authentication — Basic (username + password of the integration user) to start, or OAuth 2.0 (client ID/secret + service-account credentials) for production.
- Who gets notified — pick individuals, groups, or an on-call rotation, plus the channels (Call is the most reliable for critical incidents).
- Escalation interval — how long to wait for each recipient to acknowledge before moving to the next.
Save Connection. JAMS shows you the webhook URL — it looks like https://<your-JAMS-backend-host>/api/servicenow/webhook/{tenantId}/{flowId}. Copy it; you'll paste it into ServiceNow next.

The credentials are used only for write-back. Inbound alerts authenticate by the secret webhook URL itself, but pushing Acknowledge / Resolve back into ServiceNow requires the instance URL + integration-user credentials you entered here. Without them, JAMS can still call your team — it just can't update the ServiceNow incident.

Step 2 — Create the Business Rule that POSTs to JAMS

This is what makes ServiceNow tell JAMS "a major incident just opened."

In ServiceNow, go to All → System Definition → Business Rules → New.
Name: Notify JAMS on P1. Table: Incident [incident].
When to run tab:
- When: after
- Check Insert and Update.
- Filter Conditions: e.g. Priority is 1 - Critical (so only major incidents page your team).
Advanced tab — check Advanced, and in the Script field POST the ticket to your webhook URL. The body must include sysId (the record's sys_id); the rest is optional but recommended:

(function executeRule(current, previous) {
  var r = new sn_ws.RESTMessageV2();
  r.setEndpoint('https://<your-JAMS-backend-host>/api/servicenow/webhook/<tenantId>/<flowId>');
  r.setHttpMethod('POST');
  r.setRequestHeader('Content-Type', 'application/json');
  r.setRequestBody(JSON.stringify({
    sysId: current.sys_id.toString(),
    number: current.number.toString(),
    shortDescription: current.short_description.toString(),
    description: current.description.toString(),
    priority: current.priority.toString(),
    state: current.state.toString()
  }));
  r.executeAsync();
})(current, previous);

Submit.

Why sysId matters. The ServiceNow Table API addresses records by sys_id (the 32-character GUID), not the human-friendly number like INC0012345. JAMS stores the sys_id when the webhook arrives so it can update the exact incident later. If you only send the number, write-back can't find the record.

Step 3 — Add close-sync (so JAMS stops when the ticket is resolved)

Without this, someone resolving the incident inside ServiceNow wouldn't stop JAMS from calling the on-call. Cover it by letting the same Business Rule fire on state changes (the Update checkbox in Step 2 already does this) — JAMS treats incoming state values of Resolved (6), Closed (7), or Canceled (8) as "stop escalating."

If you prefer a dedicated rule, create a second Business Rule with Filter Conditions: State changes to Resolved, using the same script. Either way, JAMS cancels pending notifications the moment ServiceNow says the incident is done.

How the two-way flow works

ServiceNow incident created / updated (Priority 1)
   │
   ▼
Business Rule POST → /api/servicenow/webhook/<tenant>/<flow>
   │
   ▼
JAMS creates Incident (stores sys_id) + fires flow notifications (call, SMS, push…)
   │
   ▼ recipient presses 1 / 2 (or clicks button on /incidents)
   │
   ▼
JAMS PATCHes <instance>/api/now/table/incident/<sys_id>
                  { state: In Progress | Resolved, work_notes, close_code }
   │
   ▼
ServiceNow incident reflects the new state + work note
JAMS escalation stops (notifications cascade to "acknowledged")

When the call lands, after the incident summary you'll hear:

"Press 1 or say acknowledge to acknowledge this incident in ServiceNow. Press 2 or say resolve to resolve it in ServiceNow."

1 / "acknowledge" → ServiceNow incident → In Progress, with a work note recording the acknowledgment. Escalation stops; the incident stays open.
2 / "resolve" → ServiceNow incident → Resolved, with a close code and close note. JAMS marks the incident resolved.

You can also press 3 to replay the message at any time.

SMS replies

Reply to the alert SMS with 1 for Acknowledge or 2 for Resolve. JAMS confirms with a short reply. Same ServiceNow-side effect as the voice menu.

Teams / Slack / push

If your flow delivers to Teams or Slack, the alert card carries Acknowledge / Resolve buttons that do the same write-back. Push and email deliver the alert and can acknowledge the JAMS escalation, but only the interactive channels (voice, SMS, Teams, Slack, and the /incidents buttons) push state back into ServiceNow.

/incidents page

Open /incidents. ServiceNow incidents appear alongside other sources with Acknowledge and Resolve buttons. Buttons hit the same backend code as the voice/SMS path — ServiceNow stays in sync.

Auto-resolve

When ServiceNow reports the incident as Resolved/Closed/Canceled (via the Business Rule on state change), JAMS:

Marks the incident resolved.
Cancels any queued/sent notifications in the same group (no more pages for a ticket that's already handled).
Logs servicenow.auto_resolved in the audit trail.

Force-close (orphan incidents only)

If an incident gets stuck because the ServiceNow record behind it no longer exists (deleted, or a test payload), a normal Resolve would try to PATCH ServiceNow and fail. For exactly these cases the /incidents page has a Force close button that marks the incident resolved on the JAMS side and cancels pending notifications without calling ServiceNow. It's logged as servicenow.force_closed so it's distinguishable from a real resolve.

Open a ServiceNow incident from a JAMS alert

Everything above is ServiceNow → JAMS. JAMS can also go the other way: for alerts that didn't come from ServiceNow — a JAMS job failure, an email / API / webhook alert, or a manual send — a recipient can open a new ServiceNow incident straight from the alert, without leaving the phone call or chat. Great for turning "something just broke" into a tracked ticket in one step.

Opening a ticket also acknowledges the alert. It's a single Create + Acknowledge action, so JAMS stops escalating the moment the responder files the incident — no separate "press 1 to acknowledge" needed.

The new incident is pre-filled from the alert:

From the alert	ServiceNow incident field
Title / flow name	Short description
Message body	Description
Severity	Urgency + impact

Because the new incident is linked back to the alert, everything in How the two-way flow works then applies to it — a later Acknowledge/Resolve keeps it in sync, and resolving it inside ServiceNow stops any remaining JAMS activity.

Turn it on (admin, once per flow)

Make sure a ServiceNow connection exists (Step 1 above). The incident is created with those credentials, so the integration user needs permission to create incidents (the itil role covers this).
Open the flow you want — in New flow, Edit flow, or AI Helper.
In the flow's settings, tick "Let recipients open a ticket from this alert," choose ServiceNow, and pick the connection. Save.

The option only appears when your plan includes ServiceNow and a connection is configured. It isn't offered on Azure Monitor flows — those alerts are already tied to their own incident.

How a recipient opens one

However the alert reaches them, there's now one extra choice on the menu:

Voice call: the menu adds a "create ticket" option — press the number it announces, or say "create ticket."
SMS: reply with the digit shown next to "create ticket."
Teams / Slack: a Create ServiceNow incident button on the alert card.
Notifications page: a 🎫 ServiceNow ticket button next to any active alert on /notifications.

JAMS confirms with the new incident number — e.g. "Created ServiceNow incident INC0012345 and acknowledged the alert." Choosing it twice is safe: the second press just reports the incident that's already open, never a duplicate.

Choosing the resolve close code

ServiceNow usually requires a close code and close notes when an incident moves to Resolved (an out-of-the-box business rule enforces this). JAMS sends a sensible default close code and a note like "Resolved via JAMS." If your instance uses a customized close-code choice list and rejects the default, the resolve PATCH will fail with a 4xx — contact support to set the close code JAMS sends to one your instance accepts.

Verify it works (end-to-end)

In ServiceNow, create a new Incident with Priority = 1 - Critical (matching your Business Rule filter).
Within a few seconds, the on-call recipient should get a JAMS call / SMS / push.
Press 1 on the call (or reply 1). In ServiceNow, open the incident — State should flip to In Progress and a work note should appear.
Press 2 (or click Resolve on /incidents) — the incident moves to Resolved.
Create another P1, then Resolve it directly in ServiceNow — JAMS should stop escalating within ~30 seconds.

Troubleshooting

Symptom	Likely cause	Fix
JAMS never calls	Business Rule didn't fire, or the endpoint URL is wrong	Confirm the rule's When = after, Insert/Update checked, and the filter matches your test incident. Re-copy the webhook URL from the ServiceNow connection. Check the rule's script for a typo in the endpoint.
Calls land, but pressing 1 says "ServiceNow refused our credentials."	Wrong integration-user username/password, or the OAuth client is misconfigured	Re-enter the credentials in the ServiceNow connection (Edit). Confirm the user can log in to the instance directly.
Pressing 1 says "Our ServiceNow account is not authorized to update this incident."	The integration user lacks write access to the Incident table	Grant the user the `itil` role (or equivalent write access).
Pressing 2 (Resolve) fails with a 4xx	Your instance requires a specific close code JAMS isn't sending	Contact support to align the close code JAMS sends with your instance's choice list.
Pressing 1 says "ServiceNow no longer has this incident."	The `sys_id` doesn't exist (deleted, or only the number was sent)	Confirm the Business Rule sends `current.sys_id`, not the number. For a genuinely deleted record, use Force close on `/incidents`.
Reminders/calls keep coming after the ticket was resolved in ServiceNow	The Business Rule isn't firing on Update (state change)	Make sure Update is checked in the rule's When to run, or add a dedicated rule on State changes to Resolved.
"Create ticket" isn't offered on the alert	The flow's toggle is off, your plan doesn't include ServiceNow, no connection is configured, or it's an Azure Monitor flow	Enable "Let recipients open a ticket from this alert" on the flow, confirm the plan and a saved connection. Azure Monitor flows don't support it.
"Create ticket" fails with "ServiceNow connection not configured" or an authorization error	No usable connection, or the integration user can't create incidents	Add/fix a ServiceNow connection (Step 1) and give the user create rights on the Incident table (`itil`).

If you hit something not on this list, capture the time of the failed call/SMS and a screenshot of the /incidents audit log, then reach out to support — that gives us enough to trace through the backend's [ServiceNow] log lines.