ServiceNow accepts **OAuth 2.0 Client Credentials** (recommended) or **HTTP basic authentication**. Both methods authenticate as a dedicated service account; that user's roles and ACLs govern all API access. Open the **Generating Credentials** section and choose the tab for your authentication method.

Each tab explains ServiceNow roles for that authentication path. For Security Incident Response (SIR) on `sn_si_incident`, see the [ServiceNow Ticketing (Security Incident Response) Configuration Guide](/guides/provider-configuration/servicenow-ticketing-sir-setup).

## Generating Credentials

ServiceNow supports two authentication methods for this integration, shown as tabs below.

**OAuth 2.0 (recommended)** — A Client Credentials application that authenticates as a linked Application User. Access is governed entirely by that user's roles, with no REST API Access Policies required.

**Basic Credentials** — A dedicated service account with username and password. Setup is shorter: create the user, assign the ITSM roles listed in that tab, and set a password.

The same ITSM roles apply in both tabs; only how the integration authenticates differs.

OAuth 2.0 (recommended)
OAuth 2.0 requests are authenticated as the **Application User** linked to the OAuth Application Registry. Collections on that user define query, create, read, and update behavior on the Incident table, exactly as they do for Basic Credentials.

ServiceNow authenticates this method with an OAuth 2.0 **Client Credentials** application. With this approach, you authenticate an *application* (using a Client ID and Client Secret) that then acts as a linked **OAuth application user**. The application credentials themselves carry no permissions—that user's roles and ACLs determine what the integration can read or write, exactly as they would for Basic Credentials, but without embedding a username or password in the integration settings.

### 1. Verify the Client Credentials grant type is enabled

In the ServiceNow filter navigator, type `sys_properties.list` and press **Enter**. Search for `glide.oauth.inbound.client.credential.grant_type.enabled` and confirm its value is **true**.

On instances running the Zurich release or later (where the Machine Identity Console is available), this property is typically already set to **true**. If you can see the Machine Identity Console in the navigation, you can skip this step and return here only if token requests fail with `access_denied`.

If the property does not exist, click **New** and create it: set **Name** to `glide.oauth.inbound.client.credential.grant_type.enabled`, **Type** to `true | false`, and **Value** to `true`.

### 2. Create the OAuth integration

Navigate to **All > Machine Identity Console**, then click the **Inbound integrations** tab. Click **New Integration**.

In the **"Select your application connection type"** dialog, select **OAuth - Client credentials grant** ("Used for machine-to-machine access to the application without the user's context").

Fill in the **Details** section:

| Field | Value |
|  --- | --- |
| Name | A descriptive name, for example `Synqly Integration`. |
| Provider name | A label for the external system connecting to ServiceNow, for example `Synqly`. |
| OAuth application user | The service account that should own tokens issued from this integration. This is the key field—the token acts as this user, and that user's roles and ACLs govern all API access. |
| Client ID | Auto-generated. |
| Client secret | Auto-generated. |


In the **Auth scope** section, leave **Auth scope** empty and **uncheck** the **Allow access only to APIs in selected scope** checkbox.

**Unchecking "Allow access only to APIs in selected scope" is required.** When unchecked, access is governed entirely by the **OAuth application user**'s roles and ACLs. If the checkbox is left checked or an Auth scope is added, different ServiceNow REST surfaces require different scopes and will conflict with each other, producing `403: Missing required api access scope` or `403: Access to unscoped api is not allowed` errors.

Click **Save**.

The Client secret is masked after saving. Copy it before clicking Save, or use the copy icon next to the field on the saved record. Store both the Client ID and Client secret securely; you will need them when configuring the integration in Synqly.

### 3. Confirm the Application User

The **OAuth application user** is set directly on the creation form in step 2. Verify that the correct service account is selected before saving.

Do not create a REST API Access Policy that enforces a specific Auth Scope (for example on `table_api_access`) for OAuth traffic. Combining this integration with REST API Access Policies produces `403` scope-conflict errors identical to those described in step 2 above.

### Dependency chain


```
Client ID + Client Secret
        |  (authenticate)
        v
  OAuth Integration Record
        |  (acts as)
        v
   OAuth Application User
        |  (governed by)
        v
   Roles and ACLs
        |
        v
 What the token can read or write
```

The OAuth credentials themselves grant no permissions on their own—they are a key to the door. What is behind that door is defined entirely by the OAuth application user's roles, assigned in the next step below.

### 4. Assign roles to the Application User

Open the Application User you set in step 2 and, in the **Roles** tab, select **Edit...**. Assign:

| Collection | Purpose |
|  --- | --- |
| `itil` | Baseline ITSM incident operations via Table API. |
| `itil_admin` | Additional incident capabilities commonly required for integrations. |
| `snc_internal` | Collections ServiceNow expects on integration-style users for routine platform reads. |
| `personalize_decision_table_input` | Table API reads on `sys_choice` for incident status labels; omitting it often surfaces HTTP 403 on those reads. |
| `personalize_dictionary` | Required for custom field discovery against `sys_dictionary`; omitting it causes HTTP 403 when Synqly validates your custom field mappings. |


Optional collections—add only when the capability is in scope:

| Collection | Use when |
|  --- | --- |
| `u_ticket_user` | Custom extended ticketing (for example records on `u_ticket`), not only Incident. |
| `admin` | Webhooks write to the `sys_script` (Business Rules) table, which requires `admin`. There is no built-in narrower ServiceNow role for `sys_script` write access; a custom ACL role created by your administrators is the only alternative. |
| `sn_incident_write` | Narrow incident create/edit via the ITSM Roles plugin (`com.snc.itsm.roles`) when admins prefer granular roles instead of the broad `itil` bundle; not contained inside `itil`. Usually redundant if `itil` is already assigned for incidents. |


If authentication succeeds but incident data looks incomplete or incorrect—for example, records are missing, fields you expect to update stay read-only or empty, or status values show as raw codes instead of labels—the Application User's roles or ACLs are the usual cause. Confirm the roles in the tables above, especially `personalize_decision_table_input` (needed for status labels from `sys_choice`), and any custom ACLs your administrators added.

### Configure the integration

In your integration or connector settings, supply:

**URL**
The root URL of your ServiceNow instance, for example `https://<tenant>.service-now.com/`.

**Client ID**
The Client ID from the Application Registry record.

**Client Secret**
The Client Secret from the Application Registry record.

**Token URL** (optional)
Only set this if your identity provider issues tokens from a URL other than your ServiceNow instance's default OAuth token endpoint.

**OAuth Scopes** (optional)
Leave empty for a Broadly scoped Application Registry (recommended). Only set this if the registry is Securely scoped with explicit Auth Scopes—see the warning in step 2 above.

Basic Credentials
HTTP basic authentication uses a dedicated ServiceNow user (username and password). Collections on that user define Incident table access. Review the role tables in step 1, then create the integration user and assign those roles in step 2.

You typically do not need an extra custom integration role unless administrators tied an optional Incident ACL to one—in that case they create the role and ACL first, then you assign that role along with the collections in step 1.

For HTTP paths, see [Ticketing accessed provider endpoints](/guides/connectors/ticketing/accessed-provider-endpoints).

### 1. Role assignments for the integration user

Recommended minimal collections for standard Incident CRUD and query (apply when you assign roles on the integration user in the next step):

| Collection | Purpose |
|  --- | --- |
| `itil` | Baseline ITSM incident operations via Table API. |
| `itil_admin` | Additional incident capabilities commonly required for integrations. |
| `snc_internal` | Collections ServiceNow expects on integration-style users for routine platform reads. |
| `personalize_decision_table_input` | Table API reads on `sys_choice` for incident status labels; omitting it often surfaces HTTP 403 on those reads. |


Add any custom role your administrators defined for an optional Incident ACL, if they use that pattern.

Optional collections—add only when the capability is in scope:

| Collection | Use when |
|  --- | --- |
| `u_ticket_user` | Custom extended ticketing (for example records on `u_ticket`), not only Incident. |
| `admin` | Webhooks or automation touch `sys_script`; prefer a narrower role your admins define when possible. |
| `sn_incident_write` | Narrow incident create/edit via the ITSM Roles plugin (`com.snc.itsm.roles`) when admins prefer granular roles instead of the broad `itil` bundle; not contained inside `itil`. Usually redundant if `itil` is already assigned for incidents. |


`sn_incident_write` vs `itil`: ServiceNow treats these as separate. `itil` bundles many ITSM responsibilities (Incident, Problem, Change, and related permissions); `sn_incident_write` is a scoped incident write role shipped with the ITSM Roles plugin and is not inherited by `itil`. Activate `com.snc.itsm.roles` when your instance uses those granular roles. This guide's minimal bundle centers on `itil` because the incident flows commonly need that breadth plus supporting collections; if `itil` is already on the user, adding `sn_incident_write` is typically redundant for incident access. Least-privilege designs sometimes substitute granular roles such as `sn_incident_write` (with reads handled separately—for example `sn_incident_read`) instead of `itil`—only with administrator approval.

Assign the recommended minimal collections above (`itil`, `itil_admin`, `snc_internal`, and `personalize_decision_table_input`), plus any custom ACL role admins defined. Add optional collections only when a row in the optional table applies to your scope.

If authentication succeeds but incident data looks incomplete or incorrect—for example, records are missing, fields you expect to update stay read-only or empty, or status values show as raw codes instead of labels—the integration user's ServiceNow roles or ACLs are the usual cause, not the username or password. Confirm the roles in the tables above, especially `personalize_decision_table_input` (needed for status labels from `sys_choice`), and any custom ACLs your administrators added.



### 2. Create a Service Account User

Navigate to **All > Organization > Users**. Select **New**. Fill in the required fields, including **Internal Integration User**.

Once the user exists, open it, select **Edit...** on **Roles**, and assign collections from the role-assignment tables above.

Create a password for the user. Store the username and password securely.

### 3. Configure the integration

In your integration or connector settings, supply:

**URL**
The root URL of your ServiceNow instance, for example `https://<tenant>.service-now.com/`.

**Username**
The service account from [2. Create a Service Account User](#ticketing-sn-basic-step-2-service-account).

**Password**
Use with **Username** for HTTP basic authentication—that account's password.

## Custom Fields

To configure custom fields for this integration, see the [ServiceNow Ticketing Provider Custom Fields Configuration Guide](/guides/provider-configuration/servicenow-custom-fields-setup).