ServiceNow

Overview

The ServiceNow integration lets you create ServiceNow records and link existing ones directly from risks and incidents in Adversarial. A single risk or incident can have one or multiple linked records.

The integration connects to ServiceNow’s Table API over OAuth using the client credentials grant — a machine-to-machine flow that runs without a signed-in user (see ServiceNow’s OAuth client credentials grant for more detail). You choose which record tables the integration operates over (for example, Incident, Request, or a custom table), and it creates, searches, and links records across that set.

Setup

Most of the setup happens in ServiceNow, where you create a dedicated service account, grant it access to the tables you want to use, and register an OAuth client. You then enter the resulting credentials in Adversarial.

You will need administrator access to your ServiceNow instance to complete these steps.

1. Create a service account

Create a dedicated user for the integration so its activity is attributable and its access is scoped to exactly what the integration needs. Do not reuse a person’s account.

In ServiceNow, create a new User with:

• A recognizable User ID (for example, adversarial-servicenow)
• Identity type set to Machine
• Active checked

2. Create a role and grant table access

Create a role that you will assign to the service account, then grant that role read and write access to each table the integration will use. Grant access only to the tables you plan to select in Adversarial — nothing more.

Create a new Role (for example, Adversarial Integration) and leave Elevated privilege unchecked.

For each table you plan to configure in Adversarial, create read and write ACLs on that table and attach them to this role. The integration needs both read access (to search and link existing records) and create access (to file new records). Repeat this for every configured table — an ACL on one table does not extend to another.

The connection details can be saved in Adversarial before table access has been granted, so a missing ACL only surfaces later as a permissions error when creating or searching records. If that happens, verify the role has ACLs on the table in question.

Scope access per table

Create ACLs for only the tables you intend to use, and attach them to the role you assign to the service account. The integration can read, search, and create records on any table the service account can reach, so the set of table ACLs on that role is what bounds the integration’s reach.

3. Assign the role to the service account

Open the service account user from step 1 and assign the role from step 2 under the Roles tab.

4. Register the OAuth client credentials grant

The client credentials grant must be enabled on your instance before you can register a client that uses it. Enabling it is controlled by the glide.oauth.inbound.client.credential.grant_type.enabled system property, which must be set to true. See ServiceNow’s Create the client credentials system property for details.

In the Machine Identity Console under Inbound integrations, create a new connection and choose OAuth - Client credentials grant as the application connection type.

On the connection form:

• Give the connection a Name.
• Set the OAuth application user to the service account you created in step 1. This is the user the integration acts as, so it inherits the table access you granted that account.
• Under Auth scope, limit authorization to the Table API so the client can only reach the Table API.

After saving, ServiceNow generates a Client ID and Client secret. Copy both — you will enter them in Adversarial.

5. Enter the connection details in Adversarial

Enable the integration from your Adversarial tenant via Settings > Integrations. Provide:

• Instance URL — your ServiceNow instance’s base URL (for example, https://mycompany.service-now.com). It must be an https:// URL on the service-now.com domain, with no path after the hostname.
• Client ID — from the OAuth client you registered
• Client Secret — from the OAuth client you registered
• Tables — the record tables the integration may create, search, and link across

For Tables, select from the standard tables (Request, Incident, Security Incident, Remediation Task, Problem, Task) or type a custom table’s name to add it. The tables you select here must match the tables you granted the role in step 2.

Creating a New Record

In the ticketing section of a risk or incident, select ServiceNow as the ticket integration, then create or link a record.

Select + Create Ticket to create a record. The record is populated from the risk or incident:

ServiceNow field	Populated from
Short description	Title
Description	Description (falls back to the title when the description is empty)
Priority	The risk’s Urgency or the incident’s Severity (see below)

Risk Urgency / Incident Severity	ServiceNow Priority
Critical / Sev1	1 – Critical
High / Sev2	2 – High
Medium / Sev3	3 – Medium
Low / Sev4 (or unset)	4 – Low
Info / Sev5	5 – Planning

Long titles and descriptions are trimmed to ServiceNow’s field length limits.

When more than one table is configured, you choose which table to file the record into at creation time. When only one table is configured, the record is filed into that table directly.

Linking an Existing Record

Begin searching for an existing record by number or summary, and select it to link it. The search spans the tables you configured.

Unlinking

Remove a link from the same section. Unlinking removes the link in Adversarial; it does not delete the record in ServiceNow.

Note

A linked record that can no longer be loaded from ServiceNow — because it was deleted there, its table was removed from the configuration, or the table is temporarily unreachable — stays visible as an unavailable placeholder, and you can still unlink it.