ServiceNow

Overview
How to connect
Automated checks
Useful links

DSALTA connects to ServiceNow using read-only API access to collect compliance evidence automatically. Data feeds into your Data Library modules — account users for access reviews, plus ITSM incidents and change requests.

DSALTA only reads. Every request this integration makes is a read against the Users, Incidents and Change Requests tables. DSALTA has no code path that creates, modifies, or deletes anything in your instance.

DSALTA collects this integration’s data when you connect it — you can refresh it at any time with Sync from integrations on the Integrations page. The compliance checks below re-run once a day at 02:00 America/New_York.

What DSALTA reads

DSALTA reads the ServiceNow user roster — names, emails, job titles and lock status, which appears on your Access page. It also reads incidents, which appear on your Incidents page, and change requests, which appear on your Changes page — with the Environment column always reading Production. The roster query asks only for active accounts, so deactivated users are absent rather than listed as inactive, and the role column shows a user’s job title, not their ServiceNow security roles.It calls these ServiceNow endpoints:

/api/now/table/sys_user
/api/now/table/incident
/api/now/table/change_request

Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your ServiceNow environment.

Troubleshooting

Integration shows Disconnected

There is no Reconnect button. Open Integrations → Connected, click Manage on the ServiceNow card, and check the Status tab — it shows either Connected and working properly or Connection issues detected. To restore a broken connection you must Disconnect and connect again, which permanently deletes the data and tests collected from ServiceNow. This can happen when the OAuth authorization is revoked or the connected user loses the roles needed to read Users, Incidents, and Change Requests.

Data is not syncing

Confirm the connected ServiceNow user still has read access to the Users, Incidents, and Change Requests tables (for example the itil role plus a user-read role, or admin), then click Sync from integrations on the Integrations page (Connected tab) — it refreshes every connected integration at once.

DSALTA requests these scopes: useraccount.

Start in DSALTA

Open Integrations in the DSALTA sidebar, find ServiceNow, and click Connect to open the connect panel.

Before anyone can authorize, a ServiceNow administrator must register DSALTA as an OAuth client inside your own instance — ServiceNow OAuth clients are instance-specific. In your instance go to System OAuth → Application Registry, click New, choose Create an OAuth API endpoint for external clients, name it, then ask DSALTA support for the redirect URL to enter and for where to send the Client ID and Client Secret ServiceNow generates when you save — copy the secret while it is still on screen. DSALTA’s connect panel collects your instance subdomain and then opens the ServiceNow sign-in window.

Have your instance subdomain ready

You’ll enter your ServiceNow instance subdomain (e.g. dev12345 from dev12345.service-now.com) in the connect window.Enter the subdomain only — the first label of your ServiceNow URL. From https://dev12345.service-now.com that is dev12345. Do not include .service-now.com, https:// or any path.

Use a user with read roles

Connect with a ServiceNow user that can read Users, Incidents and Change Requests (e.g. the itil role for incident/change + a user-read role, or admin).DSALTA requests only the useraccount scope, which gives the connection the same access as the ServiceNow user who signs in — table-level ACLs still apply. That is why the roles on the connecting account, not the scope, decide whether Users, Incidents and Changes come across.

DSALTA pages the sys_user table for active accounts only, 100 rows at a time for up to 50 pages — about 5,000 accounts, the same cap that applies to Incidents and Changes — and records every row it reads as a person. That includes ServiceNow’s built-in accounts — admin, guest, system — and any requester or customer records in the instance, all of which land on your Access page and are then checked against your People page. Expect to deactivate or exclude non-employee accounts in ServiceNow before the access checks will pass.

Incidents and Changes are read without a state filter, so closed and cancelled records come across too, and each table is capped at roughly 5,000 rows per sync. If your instance has more history than that, the Incidents and Changes pages will hold a partial view.

Finish in DSALTA

Return to the connect panel you opened in step 1 and enter your instance subdomain. A ServiceNow sign-in window opens — sign in and approve the request to finish. ServiceNow connects over OAuth, so DSALTA never asks you to paste a password or an API key.

Once connected, ServiceNow appears on the Connected tab and the checks below begin reporting after the first sync.

Each check below re-runs once a day, at 02:00 America/New_York, while this integration is connected. Click any check for step-by-step remediation guidance.

Check	Severity	What it verifies
User access to Critical System should be valid	Info	Checks that everyone with ServiceNow access is an active employee on the People page.
Offboarded users should not have active access	High	Checks that offboarded employees no longer have active ServiceNow access.

Topic	Link
General	ServiceNow website
DSALTA	Connection error messages

Getting Connected

Identity Providers

Cloud Infrastructure

Code Repositories

Security & Monitoring

Databases

SaaS & Productivity

What DSALTA reads

Troubleshooting

​What DSALTA reads

​Troubleshooting

What DSALTA reads

Troubleshooting