Open in ChatGPTOpen in Claude

ServiceNow Audit Logs

Collect the audit trail of your ServiceNow instance in Coralogix. The ServiceNow Audit Logs integration reads your instance through the ServiceNow Table API and ingests each record as a log, so you can investigate who changed what in ServiceNow alongside the rest of your telemetry and retain that history for compliance.

It collects four tables:

• sys_audit — field-level change history for audited records
• sys_audit_delete — history of deleted records
• sysevent — records from the instance event queue
• syslog_transaction — transaction records for requests processed by the instance

Note

To create and synchronize ServiceNow incidents from Coralogix Cases, see the ServiceNow destination type. That capability is configured separately in Notification Center.

How collection works

Each of the four tables is collected independently, every 10 minutes.

Collection starts at the moment you create the integration. Records created before then are not collected — there is no historical backfill.

Each record is ingested verbatim as a JSON log, timestamped with the record's sys_created_on value and assigned the Info severity.

What you need

• A ServiceNow instance, and the admin role on that instance to register an OAuth application
• A ServiceNow user the collector authenticates as, with read access to sys_audit, sys_audit_delete, sysevent, and syslog_transaction
• A non-expiring password on that user, with multi-factor authentication turned off for it — authentication uses the OAuth password grant
• INTEGRATIONS:DEPLOY permission in your Coralogix account (required to create, update, and remove the integration)

Register an OAuth application in ServiceNow

The collector signs in with the OAuth resource owner password credentials grant, so your instance needs an inbound integration that issues a client ID and a client secret. You register it in the Machine Identity Console.

These steps describe the Australia release of ServiceNow. To check which release your instance runs, open https://<your-instance>.service-now.com/stats.do and read the Build name value.

1. Sign in to your ServiceNow instance at https://<your-instance>.service-now.com as a user with the admin role. This is your own instance, not the ServiceNow corporate website.
2. Go to https://<your-instance>.service-now.com/now/machine-identity-console/inbound-integrations/welcome. You can also select All in the top navigation, type machine identity in the filter box, select Machine Identity Console, and open the Inbound integrations tab.
3. Select New integration. ServiceNow opens the Select your application connection type dialog.
4. Select OAuth - Resource owner password credential grant, described as Used to allow a trusted app to directly collect and use the user's credential to access the application. ServiceNow opens a New record form, with Inbound integrations and Resource Owner Password Credentials in the breadcrumb.
5. Under Details, enter a Name for the integration, such as Coralogix audit log collector. Both Name and Provider name are required, and Save stays unavailable until you fill them in.
6. In Provider name, enter Coralogix. The field takes the name of the service you are integrating with, and accepts a value that is not already in the list.
7. Leave Client ID and Client secret as they are. ServiceNow generates both and shows them on the form, so there is nothing to fill in and no record to reopen afterwards.
8. Under Auth scope, find Scope validation settings and clear Allow access only to APIs in selected scope. The option is selected by default, which restricts the integration to the APIs listed in its own scopes and makes its calls to the Table API fail with a 403 response.
9. Copy the Client ID and the Client secret, which you need when you set up the integration in Coralogix. Select Unmask password to reveal the secret, or Copy client secret to copy it without revealing it.
10. Leave Advanced options at their defaults, then select Save.

Note

The Machine Identity Console is available in the Zurich release and later. On an earlier instance, register the application through System OAuth, then Application Registry, then New, then Create an OAuth API endpoint for external clients, and clear the same scope-validation setting on the saved record. Zurich and later mark that path as a deprecated user interface.

The glide.security.oauth_allow_unscoped_clients system property lifts the same restriction for every OAuth application in the instance. Coralogix recommends the per-integration setting instead, so the change stays scoped to this integration.

Verify the audit table access

Reading the four audit tables normally requires the admin role or explicit read ACLs on each table. Confirm the user you picked can list all four tables before you continue — missing read access is the most common cause of a failed setup.

Set up the integration in Coralogix

1. From your Coralogix toolbar, navigate to Data Flow, then Integrations, select ServiceNow Audit Logs, and select Connect.
2. Select Add New.
3. Define the integration settings:
   • Integration name — a meaningful name for this integration
   • Instance URL — the base URL of your ServiceNow instance, for example https://mycompany.service-now.com/
   • OAuth client ID — the client ID of the application you registered
   • OAuth client secret — the client secret of that application
   • Username — the ServiceNow user the collector authenticates as
   • Password — that user's password
   • Application name — the Coralogix application name to ingest under. Defaults to servicenow
   • Subsystem name — optional. The Coralogix subsystem name to ingest under. Leave it empty to tag each log with the name of the audit table it came from
4. Select Create. Coralogix requests an access token and reads one record from each of the four audit tables before saving. If either step fails, the error names the step that failed and the integration is not created.

Collection begins as soon as the integration is created. To change any setting later, edit the integration from the ServiceNow Audit Logs screen; the same validation runs before the update is saved.

Validate the integration

In Explore, filter by the application name you configured. When Subsystem name is empty, you see four subsystems, one per audit table. Log bodies carry the ServiceNow record as the Table API returns it, including sys_id, sys_created_on, and the table's own fields.

Allow one poll interval — 10 minutes — after setup for the first records to arrive.

Troubleshoot common issues

Setup fails while requesting a token. Cause: the instance URL, client ID, client secret, username, or password is wrong, or the user requires multi-factor authentication or has an expired password. Fix: confirm the credentials against the application registry record, and confirm the user can sign in with a password alone.

Setup fails with an error about reading a table. Cause: the token is valid but the read is rejected — either the user lacks read access to that table, or the OAuth application is still restricted to APIs in its own scope. Fix: grant the user read access to all four audit tables, and clear Allow access only to APIs in selected scope on the application.

No logs appear after setup. Cause: collection starts at creation time, so an instance with no new audit activity produces no records. Fix: generate activity in ServiceNow, then wait one poll interval.

Logs stop arriving. Cause: the ServiceNow user's password changed or expired, or the OAuth application was modified. Fix: edit the integration with the current credentials. The update is validated before it is saved.

Permissions

Resource	Action	Description
INTEGRATIONS	DEPLOY	Create, update, and remove the ServiceNow Audit Logs integration.
INTEGRATIONS	READCONFIG	View the deployed integration and its settings.

For details, see Roles and permissions.

Related resources

• ServiceNow Table API documentation
• ServiceNow documentation on creating an endpoint for external clients
• Application and subsystem names
• ServiceNow destination type