Prerequisite: Third-party connectors are available only on the Sana Enterprise tier, with one exception: the Workday connector is included for both Sana Core and Sana Enterprise.

Introduction

Connect ServiceNow to Sana to explore, search, and manage your table records, including incidents, service catalog requests, and customer service and HR cases. Sana can also search your ServiceNow knowledge base and read full policy and knowledge articles, so you can get answers from your HR and IT content without knowing the exact article name.

In summary, the connector has the following key characteristics:

Category: Support
Connector type: Real-time
Auth type: OAuth
Hosting type: Managed

Tools

Tools are the operations the agent can use when you ask Sana about ServiceNow. In practice, the agent may call more than one to complete a single request.

Tool

Add item to cart

Check order status

Checkout cart

Create table record

Delete cart item

Delete table record

Empty cart

Find users

Get article

Get article attachment

Get catalog item variables

Get current user

Get record counts by field

Get table record by ID

Get table records

List knowledge bases

List tables

Order catalog item

Search catalog items

Search knowledge base

Search records by keyword

Submit cart order

Submit record producer

Update table record

View cart

Note: This article lists the connector's full set of tools. Your workspace owner can disable individual tools for your workspace, so some of those listed here may not be available to your agents. If a tool you expected is missing, reach out to your workspace owner.

Scope and permissions

This connector uses OAuth. When you connect your account, you will need to sign into your account and grant the required permissions.

Before you start

Before anyone in your workspace can connect ServiceNow, a ServiceNow admin needs to register two OAuth applications inside your ServiceNow instance. Both are created from System OAuth > Application Registry > New, and both are required: together they issue the access tokens and authenticate the REST API requests Sana makes on each user's behalf.

1. An OAuth API endpoint for external clients

Select Create an OAuth API endpoint for external clients — recent ServiceNow releases prefix this option with [Deprecated UI], and it is still the right one to choose. Then set:

Name — anything recognizable, for example Sana.
Redirect URL — https://api.pipedream.com/connect/oauth/oa_g2oiqA/callback

Leave the remaining fields at their defaults and the Auth Scope list empty. ServiceNow generates the Client ID and Client Secret when you save.

2. An OAuth provider entry using the same credentials

Select Connect to an OAuth Provider (simplified), shown as Connect to an OAuth Provider (simplified) - Outbound on recent releases. Then set:

Name — anything recognizable, for example Sana OAuth Validator.
Client ID and Client Secret — the values ServiceNow generated on the endpoint you registered in step 1, not new ones.
Default Grant type — Authorization Code.
Token URL — oauth_token.do
Redirect URL — https://api.pipedream.com/connect/oauth/oa_g2oiqA/callback

3. Share the credentials with everyone who will connect

Each user is asked for your instance name, the Client ID, and the Client Secret when they connect, so share all three with everyone who needs the connector. Sharing them does not grant admin access: each user still signs in with their own ServiceNow account and gets their own level of access.

Note: Hardened or heavily customized instances can need more than the above, and a 504 Gateway Time-out or a similar error is a sign that yours is one of them. Assign a dedicated role and service account to the integration, and make sure that role has ACLs for the oauth_credential table as well as the tables you want Sana to reach.

Sana also reads and writes your records through ServiceNow's global Table API, so the endpoint from step 1 must not be narrowed to a single scope. If requests fail with Access to unscoped api is not allowed, set that endpoint's Scope Restriction to Broadly Scoped.

Set up instructions

Prerequisites:

You are a Sana Enterprise user – all third-party connectors except the Workday connector are available only for users on the Sana Enterprise tier.
Your Sana workspace owner has enabled this connector – if the workspace owner has disabled the connector it won't appear in the list of available connectors.
Your ServiceNow admin has completed the required set up – see Before you start above.

Step 1: Go to the connectors page in Sana

In Sana, click on your profile icon and name in the bottom left corner and select Connectors.

Step 2: Find ServiceNow in the list of available connectors

Scroll to the Available connectors section and locate ServiceNow.

Note: If you can't find a connector in this list, it means one of the following:

You've already connected it — check the ”Active connectors” section at the top of the connectors page, or
Your workspace owner has disabled this connector for your workspace — reach out to them for more information or to request that it be enabled.

Step 3: Hover the connector card and click the connect button

Hover the ServiceNow card and click the Connect button.

Tip: If you click the card itself instead of the Connect button, you'll open a connector detail page with more information about its capabilities.

Step 4: Initialize the Pipedream connection

When clicking Connect in the previous step, a pop-up will appear powered by Pipedream. Click the Continue button in the pop-up to initialize the set up.

Note: Sana uses Pipedream to connect your account. Pipedream is a Workday product, trusted by millions of people to keep their data secure.

Step 5: Provide your ServiceNow instance, Client ID, and Client Secret

In the Pipedream pop-up you'll be asked for three values for your ServiceNow account:

Instance Name — your ServiceNow subdomain (the part before .service-now.com).
Client ID and Client Secret — generated by your ServiceNow admin from the OAuth applications registered in your ServiceNow instance (see Before you start above).

Step 6: Complete the set up

You've successfully connected your ServiceNow account. Click Continue to complete the setup and start using the connector.

Known limitations

Admin pre-setup required: users cannot connect ServiceNow on their own. A ServiceNow admin has to register two OAuth applications inside your instance first, then share the resulting Client ID and Client Secret with each user who needs to connect. See Before you start above for the values these applications need.
No granular scopes: ServiceNow's OAuth implementation does not support resource-level scopes. Access is gated by the roles assigned to the connecting user (e.g. itil, admin, read_only_admin) and by table-level ACLs in your instance. Admins must ensure the connecting user has the right roles and that the relevant tables have GET/POST/PATCH/DELETE/PUT methods enabled for the operations Sana should perform.
Knowledge base access needs the Knowledge Management API: Searching and reading knowledge articles relies on ServiceNow's Knowledge Management API (the sn_km_api plugin). If it is not activated on your instance, the knowledge base tools will not return results. Article access is still governed by each user's knowledge base and article permissions.
Knowledge search quality depends on your ServiceNow configuration: Knowledge base search runs in real time against ServiceNow's own search, so how reliably an article is found depends on how your admin has configured search (for example, which fields are searchable). If an article's full body text is not indexed for search, a question that does not match its title, short description, or tags may not surface it. Sana can read an article's full text once it is found, but broad discovery search across a large knowledge base is not yet available.

Frequently asked questions

Q: If a ServiceNow admin generates the Client ID and Secret, can they be shared with non-admin ServiceNow users — and will those users get admin access?

A: Yes, the Client ID and Secret can be shared with non-admin users — sharing them does not grant admin access. The Client ID and Secret only identify the OAuth application that lets the OAuth flow start. The actual access level is determined by each user's own permissions in ServiceNow: when they connect, they authenticate with their own ServiceNow credentials and the connector mirrors their individual access.

Q: Can Sana answer a question from our knowledge base if we don't know the exact article name?

A: Yes. Sana searches your ServiceNow knowledge base by topic and then reads the full text of the most relevant articles to answer, so you don't need to know an article's title or number. How reliably the right article is found depends on your ServiceNow instance's search configuration — see Known limitations.