ServiceNow Integration Troubleshooting

This page documents the known problems with the ServiceNow integration and the steps to resolve them. Each section describes a symptom, its cause, and the resolution.

Setup

Connecting ServiceNow Is Refused

The connection is rejected when you save the integration.

Cause: Qualytics calls the instance with the credentials before storing anything, so a bad URL, a wrong credential format, or an inactive account fails at that moment rather than later.

Resolution: Check the instance URL is the full https://your-instance.service-now.com, with no trailing path. Check the credential is username:password, the two joined by a colon, rather than a token. Confirm the service account is active and not locked out in ServiceNow.

The Response Comes Back Empty or Unreadable

Saving reports that ServiceNow returned an empty response, or that its response format is invalid.

Cause: Something between Qualytics and the instance answered instead of ServiceNow, usually a login page or a proxy error page rather than the API. That happens when the URL points at the portal rather than the instance, or when a gateway intercepts the call.

Resolution: Confirm the URL reaches the instance API directly. Ask your ServiceNow administrator whether a proxy, a firewall, or an IP allowlist sits in front of it, and have the deployment's addresses allowed through.

Requests Are Rejected as Unauthorized

ServiceNow answers 401.

Cause: The credentials are wrong, or the account is locked.

Resolution: Re-enter the credential as username:password and confirm the account can sign in to ServiceNow directly. A password rotation on the ServiceNow side needs the integration updated with the new one. See Edit ServiceNow Connection.

Requests Are Rejected as Forbidden

ServiceNow answers 403 even though the credentials are right.

Cause: The service account can authenticate but cannot act on incidents. The itil role is the usual missing piece. Enterprise instances often go further and apply Access Control Lists on the Incident table or on individual fields, which deny access even to an account that holds the role.

Resolution: Give the account the itil role. If 403 persists, ask your ServiceNow administrator to confirm the account can read, create, and write on the Incident table, to check field-level ACLs on category, subcategory, assignment_group, and any custom fields you use, and to rule out a scoped-application restriction.

Creating Incidents

The Incident Is Created but Some Fields Are Empty

The incident appears in ServiceNow, but the category, subcategory, or assignment group did not take.

Cause: Those fields are matched by value, not created on demand. A category or subcategory name that differs from the instance's choice list, including by case, is dropped rather than rejected.

Resolution: Copy the names exactly as ServiceNow lists them. See Find ServiceNow Values.

The Assignment Group Is Never Set

Everything else lands, but the incident stays unassigned.

Cause: The assignment group is referenced by its sys_id, not by its display name, so a name in that field matches nothing.

Resolution: Copy the sys_id from User Administration > Groups in ServiceNow and use that. See Find ServiceNow Values.

Work Notes Do Not Appear on the Incident

Qualytics reports the comment as posted, but the incident shows no work note.

Cause: Writing a work note is a separate permission from creating the incident, so an account that can open incidents may still be unable to annotate them.

Resolution: Ask your ServiceNow administrator to allow the service account to add work notes to incidents.

Freshness and Status

A Linked Incident Shows an Unknown Status

The ticket card reports Unknown instead of a state name.

Cause: Two different things produce this. Either the state could not be read back at all, because the credentials stopped working or the incident was deleted in ServiceNow, or the incident sits in one of the two states Qualytics does not recognize by name, Awaiting User Info (4) and Awaiting Problem (5), which read back as Unknown (4) and Unknown (5).

Resolution: The number in brackets tells the two apart. Unknown (4) or Unknown (5) is the expected reading for those states and needs nothing. A bare Unknown points at the connection, so confirm the incident still exists and that the credentials are still valid. See Edit ServiceNow Connection.

Changes Made in ServiceNow Take a Long Time to Appear

An incident moves state in ServiceNow and Qualytics still shows the old one for a while.

Cause: ServiceNow cannot notify Qualytics the moment an incident changes, so there is no instant path the way there is for Jira. Qualytics reads incidents back when the anomaly is opened and on a background sweep.

Resolution: Open the anomaly to force a read. There is no webhook to register for ServiceNow, so a deployment that needs shorter delays has to shorten the sweep interval instead. See How It Works.

The Incident Does Not Move When the Anomaly Changes

The anomaly is acknowledged or archived, a work note appears on the incident, but its state stays where it was.

Cause: By default a status change adds a work note without moving the incident. Moving it is what Anomaly status sync turns on, and it only acts on incidents that are not read only.

Resolution: Turn on Anomaly status sync in the integration settings and map the anomaly statuses to incident states. Confirm the linked incident is not set to read only. See How It Works.

A Comment Written in ServiceNow Is Not on the Anomaly

Someone adds a work note in ServiceNow and nothing shows on the anomaly's timeline.

Cause: Comment sync runs one way for ServiceNow. Qualytics writes work notes onto the incident, and does not read them back.

Resolution: None. This is by design, and it is the difference the ticketing overview records against Jira, where comments mirror both ways.

Limitations