ServiceNow

What the Integration Does

The integration uses a dedicated ServiceNow service account to read data from specific tables using the ServiceNow Table API. All access is read-only. No data is written, updated, or deleted in your ServiceNow instance.

Data is extracted incrementally based on the sys_updated_on timestamp, so only new or modified records are pulled after the initial sync.

Step 1: Create a Service Account

Create a dedicated local user account for the integration. This keeps access auditable and separate from any individual's credentials.

1. Navigate to User Administration > Users
2. Click New
3. Fill in:
   • User ID: svc_devgrid_sync (or your preferred naming convention)
   • First name: DevGrid
   • Last name: Sync Service
   • Active: checked
   • Web service access only: checked (recommended)
   • Password: set a strong password
4. Click Submit

Provide the User ID and password to your DevGrid contact via a secure channel (e.g., a password manager share or encrypted message). Never send credentials over email.

Step 2: Grant Read Access to Required Tables

The service account needs read access to the tables listed below. The simplest approach is to create a custom role and assign table-level ACLs.

Option A: Create a Custom Role (Recommended)

1. Navigate to User Administration > Roles
2. Click New
3. Create role: u_devgrid_read (or similar)
4. Assign this role to the svc_devgrid_sync user

Option B: Use Existing Roles

If your organization already has a read-only analytics or reporting role that covers these tables, you can assign that instead. Common roles that may provide partial coverage:

• itil - covers incident, problem, change, and CMDB tables
• cmdb_read - covers CMDB tables
• sn_vul.read - covers Vulnerability Response tables

You will likely need a combination or a custom role to cover all tables.

Assign Table-Level ACLs

For each table listed in the table below, ensure the service account's role has a read ACL. Navigate to System Security > Access Control (ACL) and verify or create rules for:

• Type: record
• Operation: read
• Name: (the ServiceNow table name from the list below)
• Role: u_devgrid_read (or whichever role you assigned)

Step 3: Required ServiceNow Tables

The integration reads from the following 32 ServiceNow tables. This is the complete list. All access is read-only.

ITSM - Incident, Problem & Change Management

CMDB - Configuration Management

Vulnerability Response

Organization & Assets

Custom / Extended Tables

Depending on your deployment, the integration may also pull from custom tables (prefixed with u_ or x_). Your DevGrid contact will provide the specific list of custom tables required for your environment. If a custom table does not exist in your instance, the integration will skip it gracefully — no errors will occur.

When custom tables are identified, grant the service account read access to those tables using the same ACL approach described above.

Step 4: Verify Access

Before handing off credentials, verify that the service account can read the required tables.

Quick Test via Browser

1. Log in to your ServiceNow instance as the service account
2. Navigate to the following URL (replace YOUR_INSTANCE):

   https://YOUR_INSTANCE.service-now.com/api/now/table/incident?sysparm_limit=1

3. You should see a JSON response with one incident record
4. Repeat for a few other tables, especially the vulnerability tables (sn_vul_entry, sn_vul_vulnerable_item) since those often require additional permissions

Quick Test via cURL

curl -s -u 'svc_devgrid_sync:PASSWORD' \
  -H 'Accept: application/json' \
  'https://YOUR_INSTANCE.service-now.com/api/now/table/incident?sysparm_limit=1'

A successful response returns HTTP 200 with a JSON body containing a result array. If you get HTTP 401 or 403, the account lacks access to that table.

Test All Tables

Run this check for each table in the list above. Any table returning 401/403 needs an ACL rule added for the service account's role.

TABLES=(
  incident problem change_request change_task
  cmdb_ci cmdb_ci_service cmdb_ci_appl cmdb_ci_computer
  cmdb_ci_server cmdb_ci_database cmdb_ci_business_app
  cmdb_rel_ci cmdb_rel_type cmdb_software_product_model
  sn_vul_entry sn_vul_vulnerable_item sn_vul_app_vulnerable_item
  sn_vul_detection sn_vul_app_scanned_application sn_vul_app_vul_entry
  sn_vul_m2m_entry_cwe sn_vul_cwe sn_sec_cmn_src_ci
  sys_user sys_user_group core_company cmn_cost_center
  service_offering sys_db_object
  # Add any custom tables (u_ or x_ prefixed) provided by your DevGrid contact below:
)

for TABLE in "${TABLES[@]}"; do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
    -u 'svc_devgrid_sync:PASSWORD' \
    -H 'Accept: application/json' \
    "https://YOUR_INSTANCE.service-now.com/api/now/table/${TABLE}?sysparm_limit=1")
  echo "${TABLE}: ${STATUS}"
done

Expected output for each table is 200. Tables returning 404 may not be installed (e.g., sn_vul_* tables require the Vulnerability Response module to be licensed).

Step 5: Network & Firewall Considerations

The integration connects outbound from DevGrid infrastructure to your ServiceNow instance over HTTPS (port 443).

• If your ServiceNow instance is publicly accessible (e.g., yourcompany.service-now.com), no firewall changes are needed.
• If your instance restricts inbound connections by IP, contact your DevGrid representative for the list of source IP addresses to allowlist.

Step 6: Provide Credentials to DevGrid

Share the following with your DevGrid contact:

Use a secure method to transmit the password (password manager share, encrypted message, etc.).

API Usage & Rate Limiting

The integration is designed to be respectful of your ServiceNow instance:

• Read-only: no writes, updates, or deletes
• Paginated requests: fetches records in batches (default 1,000 per request)
• Throttled: configurable delay between API requests (default 1 second)
• Concurrency: limited concurrent requests (default 5)
• Incremental: after the initial sync, only new/modified records are fetched
• Retry-aware: respects Retry-After headers and backs off on HTTP 429 responses

Typical API usage during a full initial sync depends on the volume of data in your instance. Incremental syncs afterwards are significantly lighter.

Frequently Asked Questions

Q: Does the integration write any data to our ServiceNow instance?
A: No. All access is strictly read-only via the Table API.

Q: What happens if a table doesn't exist in our instance?
A: The integration logs a warning and skips that table. This is expected for custom tables (u_ prefix) or optional modules like Vulnerability Response.

Q: Can we restrict which records the integration pulls?
A: Yes. The integration supports configurable filters and date ranges on the DevGrid side. Contact your DevGrid representative to customize.

Q: How often does the sync run?
A: Sync frequency is configured on the DevGrid side, typically daily. Contact your DevGrid representative for your specific schedule.

Q: Which ServiceNow versions are supported?
A: The integration uses the standard Table API, which is available on all currently supported ServiceNow releases (Tokyo, Utah, Vancouver, Washington DC, Xanadu, and newer).

Q: Do we need any ServiceNow plugins or store apps installed?
A: No additional plugins are required for ITSM and CMDB tables. The Vulnerability Response tables (sn_vul_*) require the Vulnerability Response application to be installed and licensed. The Security Operations tables (sn_sec_*) require Security Incident Response or a related SecOps module.

Support

If you have questions about the integration or need help configuring access, contact your DevGrid representative or reach out to [email protected].