Skip to main content

ServiceNow Context Connector

Learn how to ingest ServiceNow identity and asset data into Torq to build organizational context for alert enrichment and investigation.

Overview

The ServiceNow context connector ingests identity and asset data from ServiceNow into Torq's organizational Context Graph. It pulls user accounts, groups, group memberships, role assignments, and CMDB computers and their relationships, giving Torq the context it needs to enrich alerts, support investigations, and power the Context Graph page.

What it ingests

The connector reads the following ServiceNow tables. The integration user must have read access to all 13.

Core tables

  • sys_user: Users, including department, title, manager, location, and VIP status

  • sys_user_group: Groups

  • sys_user_grmember: Group memberships

  • sys_user_has_role: Role assignments

  • cmdb_ci_computer: Computers and servers, including assigned user, owner, and managed-by relationships

  • cmdb_rel_ci: Relationships between configuration items

Lookup tables

These tables include names and labels for the fields above.

  • cmn_department

  • cmn_location

  • core_company

  • cmn_cost_center

  • cmdb_model

  • cmdb_rel_type

  • sys_user_role

Key benefits

  • Simplified setup: Configure ingestion through a guided UI. No custom workflows or API logic required.

  • Richer triage: Auto Triage uses the context graph to enrich alerts with user identity, department, group memberships, and role assignments, helping analysts judge severity faster.

  • Asset context: CMDB data links devices and infrastructure to the users who own or manage them.

  • Built-in reliability: Pagination, state tracking, and error handling are managed automatically to ensure consistent data delivery.

Common scenarios

The same Context Graph powers multiple use cases, regardless of which vendors are connected.

Improving alert triage with organizational context

When an alert involves a user or device, Auto Triage enriches it with context from the Context Graph, including identity, department, role, and group memberships. This context is incorporated into the triage verdict and displayed in the alert's Context Graph section, helping analysts assess risk more quickly.

Investigating entities and relationships

The Context Graph page lets analysts explore users, devices, and their relationships without switching between vendor consoles. Common questions include:

  • Who owns this device, and who manages it?

  • Which groups and roles does this user have?

  • What infrastructure is this user associated with?

  • How are these entities connected?

By centralizing organizational context, the Context Graph enables faster investigations and more informed security decisions.

Prerequisites

  • ServiceNow Washington DC release or later: The connector uses the OAuth 2.0 client credentials grant type, which requires this release or later.

  • ServiceNow admin access: Required for the one-time setup steps below.

  • Read access to all 13 tables: The integration user must have read access to the 6 core tables and 7 lookup tables listed in the What it ingests section above.

How to use

Configure ServiceNow

Enable the client credentials grant

  1. Open system properties: Go to All, type sys_properties.list, and press Enter.

  2. Find the property: Locate glide.oauth.inbound.client.credential.grant_type.enabled. If it does not exist, create it with Type set to true | false.

  3. Enable the grant: Set Value to true and save.

Create an integration user

  1. Open user management: Go to User Administration > Users > New.

  2. Set the user ID: Enter a service account name, for example svc_torq.

  3. Configure access: Select Web service access only and Active. No password is needed.

  4. Add roles: In the Roles tab, add the roles required for read access to the connector's tables. If no roles are required on your instance, leave the tab empty.

Finding required roles: Go to All, type sys_security_acl_list.do, and press Enter. Filter by Type = record and Operation = read, then search each table name. Open each ACL and check the Requires role list. An empty list means any authenticated user can read that table. If Table API and Aggregate API records appear under Type = REST_Endpoint and are active, also add the snc_platform_rest_api_access role.

Create the API authentication scope

  1. Open auth scopes: Go to All, type sys_auth_scope.list, and press Enter. Click New.

  2. Name the scope: Set both Name and Scope to torq_read and save.

  3. Open REST API auth scopes: Go to System Web Services > API Auth Scope > REST API Auth Scope. Click New.

  4. Link the Table API: Set REST API to Table API, HTTP method to GET, and Auth scope to torq_read. Save.

  5. Link the Aggregate API: Repeat the previous step with REST API set to Aggregate API.

Create the OAuth client

  1. Open inbound integrations: Go to System OAuth > Inbound Integrations > New integration > OAuth – Client credentials grant.

  2. Set the application user: Set OAuth Application User to the user created in the previous section.

  3. Add the scope: Under Auth scope, add torq_read.

  4. Save and copy credentials: Save, then copy the Client ID and Client Secret.

Set up a context connector instance in Torq

  1. Open connector setup: Go to Integrations > Context Graph > ServiceNow Context Connector and click Add Instance.

  2. Configure connection details:

    • Name: Enter a descriptive name for the connector instance.

    • Client ID: Enter the client ID copied in the previous section.

    • Client Secret: Enter the client secret copied in the previous section.

    • ServiceNow Instance: Enter the instance name only, in lowercase. For https://acme.service-now.com, enter acme.

    • Token URL: Enter https://<instance>.service-now.com/oauth_token.do, replacing <instance> with your instance name. The Token URL must use the same instance as the field above.

  3. Save configuration: Click Add to create the connector. Ingestion starts automatically.

You've successfully set up the ServiceNow context connector in Torq. With the instance configured, Torq will continuously ingest users, groups, group memberships, role assignments, and CMDB computers into the Context Graph, making it available for alert enrichment in Auto Triage and for investigation on the Context Graph page.

If a data table is unavailable due to insufficient permissions, Torq skips that table and continues ingesting the rest. Only the unavailable subset is missing; other data is unaffected.

Troubleshooting

  • Token request fails with access_denied: Verify that the glide.oauth.inbound.client.credential.grant_type.enabled property is set to true, that an OAuth Application User is set on the OAuth client, and that the torq_read scope is added.

  • A table returns no data: The integration user's roles do not grant read access to that table. Check the ACLs for the table and add the required role to the user.

  • API returns 401 or 403 for every table: The torq_read scope is not linked to both the Table API and the Aggregate API, or the HTTP method on those records is not set to GET.

Related Articles
Did this answer your question?