ServiceNow Sync Behavior

What the integration does on each operation: the incidents it creates and links, the two sync modes, how statuses travel through the mapping, and how comments are carried. For the connection model and the field mapping, see How the ServiceNow Integration Works.

Create Ticket

Creates a ServiceNow incident from a Qualytics anomaly with:

Required field: short_description, pre-filled from the anomaly
Optional fields: description, state, priority, urgency, impact, category, subcategory, assignment_group, assigned_to
Set by the integration: the record is always created on the Incident table, by the integration's service account. The caller cannot be set from Qualytics
Auto-included: the anomaly's ID, status, type, failed checks, and a link back to the Qualytics anomaly, appended to the description

When the starting state is Resolved, Closed, or Canceled, a close code and close note are filled in automatically, because ServiceNow refuses those states without them.

A Create Ticket flow action creates the incident automatically. Its summary and description are templates, so every incident names what it is about.

Link Existing Ticket

Links an existing ServiceNow incident to an anomaly. Unlike Jira, which leaves the issue untouched, ServiceNow's link writes to the incident:

The anomaly's details are appended to the existing description
A work note records the linkage

Incident States

ServiceNow fixes the incident states rather than letting each project define them, which is why there is no project or workflow to choose while connecting.

State code	State name	Description
1	New	Created but not yet worked on
2	In Progress	Work is actively being done
3	On Hold	Waiting for external input or resources
4	Awaiting User Info	Paused awaiting input from the requester
5	Awaiting Problem	Awaiting resolution of a related problem
6	Resolved	Fixed or addressed
7	Closed	Complete and verified
8	Canceled	Canceled without resolution

The Status field accepts either the numeric code or one of the six recognized names. States 4 and 5 have to be given as their code, and an incident already sitting in one of them reads back in Qualytics as Unknown (4) or Unknown (5) rather than by name.

Sync Anomaly Status

When an anomaly's status changes in Qualytics, every two-way linked incident:

Receives a timestamped work note, in the form [2024-01-15 10:30:00 UTC] Qualytics Anomaly Status: Acknowledged
Is moved to the mapped state when Anomaly status sync is on

Note

By default a status change adds a work note but does not move the incident. Turn on the Anomaly status sync switch in the integration settings to move it as well.

Read only and two-way sync

The Sync Settings group of the ServiceNow integration settings has one switch whose title reads Two-way sync when it is on and Read only when it is off. With two-way sync, work notes and state changes are posted to every linked incident. With read only, Qualytics reads the incidents' state and short description back and writes nothing to ServiceNow. The integration setting is the master: while it is two-way, each ticket card on an anomaly has its own Two-way / Read only button that narrows that one incident to read only. While the integration is read only, the card hides the button, because no incident can be written to.

Anomaly status sync

The Sync Settings group also holds a box with its own switch and a Mapping row that opens the Status Mapping dialog. Off, the box reads Anomaly status not synced. On, it reads Anomaly status sync with a Two-way or Read only badge that follows the switch above. Status sync is off by default.

The dialog has one row per anomaly status (Active, Acknowledged, Resolved, Duplicate, Invalid, Discarded), each with a combobox of the six recognized incident states. Clearing a row leaves it unchanged: that anomaly status moves no incident, and no incident state pulls the anomaly into it. Apply stays disabled while every row is unchanged, so at least one row must be mapped.

With the switch on:

Anomaly to incident (two-way incidents only): when an anomaly's status changes, each incident is moved to the mapped state. Nothing moves when the incident is already there. The work note is posted as before.
Incident to anomaly: when an incident changes state, Qualytics looks at every incident linked to the anomaly, two-way and read only alike. The anomaly moves only when all of them sit at states mapped to the same anomaly status. One incident still open keeps the anomaly where it is until it closes too. An archived anomaly is never moved by an incident, and a state that is not in the mapping never moves anything.

Read only incidents are never moved by Qualytics, but their state counts when deciding whether the linked incidents agree. An anomaly changed by its incidents behaves like one changed by a person: its two-way incidents follow, flows on Anomaly Status Change run, and the timeline records the change.

Sync Comments

A comment added to an anomaly in Qualytics is posted to every two-way linked incident as a work note, in the form Comment from Qualytics: <the comment>.

The work note carries the comment as plain text, so a mention arrives as a raw text code rather than as the formatted name you saw when typing it, and the mentioned user is notified in Qualytics only. A reply arrives as its own work note with no indication of which comment it answers, because work notes are a flat list. The anomaly's Timeline in Qualytics keeps the full thread with its structure.

Comments from ServiceNow

Nothing. Comment sync runs one way here, which is the main behavioral difference from Jira: work notes written in ServiceNow are not read back into Qualytics, and neither are edits or deletions of them. The Jira integration mirrors comments in both directions.