ServiceNow

Connect ServiceNow so Suger AI can work with your incidents, change requests, and service catalog.

Overview

ServiceNow is an IT service management platform covering incidents, problems, change management, and a service catalog. Connecting it lets the Suger AI agent read and act on your ITSM records from a Suger workflow or chat.

Org-Level vs User-Level

Org-Level: Supported, using the OAuth 2.0 client-credentials grant against your own ServiceNow instance.

User-Level: Not currently available. ServiceNow’s OAuth client must be registered inside your own instance rather than centrally, so there is no single Suger app your users could sign in to. Supporting per-user connections would mean each user’s sign-in borrowing your instance’s client — a dependency Suger does not yet model.

How the connection works

The OAuth client is registered in your ServiceNow instance, and Suger acts as the OAuth Application User you attach to it. Suger exchanges the client ID and secret for an access token against your instance and re-mints it as needed — there is no Suger-owned ServiceNow app, because the authorize endpoint is per-instance.

Create Integration (Org-Level)

Prerequisites

• Washington DC release or later. Earlier releases do not support the client-credentials grant at all.
• The system property glide.oauth.inbound.client.credential.grant_type.enabled set to true.
• An OAuth Application User on the OAuth record. Suger acts as this user, so its roles set the ceiling on everything the integration can do. Grant it the itil role at minimum; a few operations additionally need admin (see Suger AI Tools).
• Permission to create an application registry entry (typically the admin role).
• The Suger Admin role — connecting, disconnecting, and running an integration’s actions are all admin-only in Suger.
• A decision on auth scope enforcement — see Auth scope below. Suger requests no ServiceNow auth scope, so leaving enforcement on with no scope selected produces a connection that authenticates but cannot call anything.

Step 1 — Enable the client-credentials grant

ServiceNow does not ship this property; you create it.

1. Go to All → System Properties → All Properties.

2. Make sure your application scope is Global — the property has no effect in a scoped app.

3. Click New and enter:

   Field	Value
   Name	glide.oauth.inbound.client.credential.grant_type.enabled
   Type	`true
   Value	true
   Application	Global

To confirm, filter the list on Name is that value — you should get exactly one row reading true. Filtering with >= returns the next property alphabetically instead, which looks like a match but isn’t.

Step 2 — Create the integration user

The client-credentials token acts as this user, so its roles are the ceiling on everything Suger can do. Use a dedicated account, never a real person’s.

1. Go to All → User Administration → Users and click New.
2. Set User ID to something identifiable, for example suger.integration.
3. Set Identity type to Machine. Leave Internal Integration User unchecked — that flag exists to bypass WS-Security on SOAP interfaces and is not what you want here.
4. Submit. No password is needed; this account never signs in interactively.
5. Reopen the record. In the Roles related list click Edit, add itil, and save. Several inherited roles appear beneath it — that is normal.

Step 3 — Register the inbound integration

1. Go to All → System OAuth → Application Registry and click New.
2. Choose New Inbound Integration Experience. The [Deprecated UI] entries below it still work, but they hide the OAuth application user field behind Configure → Form Layout.

3. In the Machine Identity Console, click New integration, then pick OAuth - Client credentials grant — “machine-to-machine access to the application without the user’s context”.

4. Fill in the Details section:

   Field	Value
   Name	Suger
   Provider name	Suger — free text naming the service you are integrating with; it is inventory metadata only and is not read during the token exchange
   OAuth application user	the user from step 2
   Client ID / Client Secret	generated by ServiceNow — copy both now
   Active	checked

5. Set the Auth scope section as described below, then save.

Step 4 — Connect in Suger

In the Suger console, open Settings → Integrations, click Connect on ServiceNow, and enter:

Suger exchanges the pair for an access token and re-mints it as needed. Client-credentials tokens last about 30 minutes and carry no refresh token, which is expected.

Auth scope

On releases with the Machine Identity Console, the inbound-integration form has an Auth scope section, and its Allow access only to APIs in selected scope checkbox is enabled by default with no scope selected. Saved in that state, the integration authenticates successfully and then returns 403 on every call, because a token with no scope matches no scope-listed API.

Two supported configurations. Prefer the first — it is verified to work and avoids ServiceNow labelling the client Broadly scoped.

Scope the client to the APIs Suger uses

Click Create auth scope, name it suger, then in Limit authorization to the following APIs — a multi-select of registered API definitions, not URL paths — add:

Leave Allow access only to APIs in selected scope checked, and save.

Create a dedicated scope rather than extending an existing one. ServiceNow warns that editing a scope’s API list affects every client sharing it — a scope used only by Suger keeps later revisions safe.

Fallback: turn enforcement off

Uncheck Allow access only to APIs in selected scope. Access then falls back to the acting user’s access controls and API policies, which is the model this connector was built around — the itil role on the OAuth Application User is the ceiling.

ServiceNow labels the client Broadly scoped in this state and flags it in the Machine Identity Console’s security findings. That is accurate: the role is the only boundary. It remains the configuration Suger is known to work with, so choose it deliberately rather than as an oversight, and keep the acting user’s roles as narrow as your tools require.

Troubleshooting

To check the ServiceNow half on its own, before involving Suger:

curl -s -X POST 'https://YOUR_INSTANCE.service-now.com/oauth_token.do' \
  -d 'grant_type=client_credentials' \
  -d 'client_id=YOUR_CLIENT_ID' \
  -d 'client_secret=YOUR_CLIENT_SECRET'

Suger AI Tools

When ServiceNow is connected, the Suger AI agent can work your ITSM records through Suger’s built-in tools (40 actions).

Org-level: Every tool runs as the instance’s OAuth Application User. If a tool returns a permission error, that user is missing a role — start with itil.

Edit Integration

Editing is not supported. To rotate the client secret or point Suger at a different instance, delete the integration and create it again.

Delete Integration

Click the 🗑️ button next to ServiceNow in the Integrations list. The stored client pair is destroyed with the integration record. Delete the application registry entry in ServiceNow too if you want to revoke access from that side.