ServiceNow
Next steps
Define and manage message templates for notification destinations in Presets overview.
Define and manage message templates for notification destinations in Presets overview.
This guide explains how to integrate Coralogix with ServiceNow to automatically create, update, and synchronize ServiceNow records from Coralogix Cases. It covers what the integration does, how the components work together, how to set it up step-by-step, and how to verify and operate it in production.
The Coralogix ServiceNow integration connects Coralogix Cases with ServiceNow records (Incidents by default).
Once configured, it enables you to:
This allows teams to manage the incident lifecycle in ServiceNow, while Coralogix is used for alerting, investigation, and troubleshooting.
The Coralogix ServiceNow app is an official, no-cost application provided by Coralogix and available through the ServiceNow Store. It follows ServiceNow certification and best-practice implementation requirements.
Install the app and assign the required roles from the Coralogix listing on the ServiceNow Store. Open Links and Documents on that listing for the official installation guide, which covers app setup and the role a ServiceNow administrator assigns to the integration user used by the connector.
Understanding the main components helps explain how data flows between Coralogix and ServiceNow.
The Case notifications table is a Coralogix-owned table in ServiceNow that receives incoming events from the Coralogix Notification Center.
Every Coralogix Case event, such as case created, acknowledged, updated, and closed creates a new record in this table.
These records act as the initial trigger for processing inside ServiceNow.
The Case object is the core synchronization layer of the integration.
It represents the logical relationship between:
The Case object:
By default, the target table is Incident, but this can be changed if required.
Processing logic is part of the Case object.
When a Case Notification is received:
After processing, updates are applied to the configured target table (Incident by default).
This ensures a one-to-one relationship between a Coralogix Case and a ServiceNow record.
Case policies define how data moves into and out of ServiceNow.
Inbound policies define what happens in ServiceNow when Coralogix Case events are received.
Coralogix provides an out-of-the-box inbound policy that:
You can customize inbound behavior by:
Incident is the only table mapped out of the box. If you change the target table to any other table, such as Event or a custom table, the out-of-the-box field mapping no longer applies. You own the field mapping for that table and must complete it with your ServiceNow administrator. Records sent to an unmapped table are created empty and fail with an error. Custom target tables and custom configurations fall outside Coralogix's support scope, and you are responsible for maintaining them.
Outbound policies enable bi-directional synchronization.
They define how ServiceNow record state changes are reflected back in Coralogix Case updates.
When bi-directional synchronization is enabled, the following mappings apply:
These mappings ensure that actions taken during incident handling in ServiceNow are accurately reflected in the Coralogix Case lifecycle.
Advanced update options, such as synchronizing comments, assignments, or additional fields, are planned for future phases and are not currently available.
A Coralogix Connection record is automatically created in ServiceNow when you configure the ServiceNow connector in Coralogix.
This record:
It requires a Coralogix API key with the appropriate permissions.
On the Coralogix side, the integration is represented by a ServiceNow connector in the Notification Center.
The connector:
Once created, the connector can be used in routing rules.
A typical end-to-end flow looks like this:
To allow Coralogix to send Case notifications to ServiceNow:
The connector is now available for routing rules.
Routing determines which Cases are sent to ServiceNow.
Open an alert definition
Add routing labels, for example:
routing.group:sre
routing.environment:prod
Save the alert
true or a specific Case conditionMatching Case notifications are now sent to ServiceNow.
Generate or use an existing team API key from the API keys UI containing the cases role.
Important behavior rules:
To disable closed-state synchronization, remove the closure condition from the outbound policy.
Symptom: ServiceNow records are created, but their fields are empty and the delivery shows an Error status. The failure reason is similar to:
ConversionError: The undefined value has no properties ... status 500 Internal Server Error
Cause: The target table was changed away from Incident without completing the field mapping for the new table. The out-of-the-box mapping applies only to Incident, so records sent to an unmapped table have no fields to populate.
Resolution:
To find the failure reason for a specific notification, open the failed notification delivery in Notification Center and review its error message.
Once live: