SolarWinds Alert Integration Application End-to-End Flow
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 hours ago
Hello Folks,
While exploring with the SolarWinds Alert Integration application, I put together the complete flow of how alerts are created, updated, and closed in ServiceNow. Sharing it here in case it helps anyone setting up or troubleshooting the integration.
- Initial Setup
Start by installing the SolarWinds Alert Integration application from the ServiceNow Store. The application delivers all required components, including the connection, tables, transform maps, scripts, and reply rules used by the integration. These components are created by the application and normally do not need to be built manually.
Next, create a dedicated integration account, such as for example "solarwinds.integration", and configure it for Web Service Access Only. SolarWinds uses this account when sending messages to ServiceNow. Assign the x_sow_intapp.integration_user role so the account has permission to process incoming alerts.
For security reasons, generate a password for the integration account and store it within SolarWinds. Avoid sharing the password in any documentation or screenshots.
- Important Configuration
Before testing the integration, verify the incident closing states. The integration expects the property value to be set to 7,8, where:
Navigation - Solrwinds Alert Integration - Configuration - Properties
- State 7 = Closed
- State 8 = Canceled
Field matching is also name-based:
Navigation - Solarwinds Alert Integration - Configuration - Incident Reference Field Mappings
- Users are matched by User Name
- Assignment Groups are matched by Group Name
- Configuration Items are matched by CI Name
This means the values sent from SolarWinds must match existing records in ServiceNow.
Navigation - Solarwinds Alert Integration - Configuration - Incident Field Redirections
For backward compatibility, any incoming value for incident_state is automatically redirected to the state field, allowing older SolarWinds messages to continue updating incidents successfully.
- Connecting SolarWinds to ServiceNow
In SolarWinds, register the ServiceNow instance URL:
https://<your-pdi>.service-now.com
This tells SolarWinds where to send alert information.
After the instance is registered, associate the SolarWinds alert with the configured ServiceNow account. From that point:
- A new alert creates a new incident.
- A cleared alert updates the existing incident.
- What Happens When an Alert Is Sent?
When an alert is triggered, SolarWinds sends a SOAP request to:
x_sow_intapp_incident_integration.do?SOAP
The request contains alert details along with the integration credentials.
As soon as the message reaches ServiceNow, the integration account is validated. If authentication fails, the message is rejected and no further processing occurs.
If authentication succeeds, the payload is stored in the Incident Integrations table. These records are typically retained for approximately eight days and can be useful during troubleshooting.
- How Incidents Are Created or Updated
The transform map then processes the incoming record.
- If no ServiceNow incident ID exists, a new incident is created.
- If an incident ID is provided, the existing incident is updated.
The integration script (SWIAPI) reads the payload and populates fields such as:
- Caller
- Assignment Group
- Configuration Item
using the matching records found in ServiceNow.
The incident is also marked as SWI, making it easy to identify incidents originating from SolarWinds.
- Reply Processing
Whenever the incident is updated, the Incident Events business rule runs and creates a reply record.
SolarWinds reads these reply records to stay synchronized with ServiceNow and to track any changes made to the incident after creation.
- Alert Closure Flow
When the alert is cleared in SolarWinds, the same incident ID is sent back to ServiceNow with a state value of 7.
The transform map identifies the existing incident, updates it, and moves it to the Closed state instead of creating a new record.
Final Thoughts
The integration is straightforward once the account, roles, state mappings, and field mappings are configured correctly. Most issues I've encountered during testing were related to authentication, name-based record matching, or incorrect state configuration, so those are good areas to verify first when troubleshooting.
Hope this helps! Please mark it as helpful if it worked for you.
