Troubleshoot ServiceNow

This topic provides frequently asked questions about the ServiceNow^® integration.

How do I check that my ServiceNow integration is set up correctly?

Make sure you have installed the ServiceNow Alert integration app, created a user, and integrated the ServiceNow instance.

When creating or editing an alert, add the Create ServiceNow incident action. Make sure that drop-downs in the Configure Action popup provide reasonable options.

Add the action to the alert and click Simulate to test creating an incident. Check that the incident was created. If the test passes, you should be all set up.

To fully test the integration, create conditions to make the alert trigger and check that the action works as expected. You can also check that your alert works as described in What happens when....

Why are my incidents reopening right after I resolve them?

When you change an incident's state to the reset state manually and the alert that created this incident is still active, the incident transitions to the reopen state.

To forcefully close the incident, put it in one of the closing states.

Why are closed incidents reopening instead of creating a new incident?

Make sure the final closed state is one of the closing states.

If you never want to reopen an incident, set the reset state to a closing state.

Why are my incidents reopening after I changed the closing states?

This is a known issue. When you add a state to the group of closing states, the change is not reflected on incidents already closed according to the original definition of closing states.

If an incident was closed and the state it was in was not originally among the closed states, the incident gets reopened when the alert triggers again. After that (when its state is among closed states), the incident will not reopen any more.

You can also resolve this by updating the mapping in the database. Contact support for the script to run.

Why are my incidents not being reopened and only receive work notes?

Make sure you define the reset state, which is used to show that an incident is resolved. Only incidents in the reset state get reopened. This is to stop the incident from transitioning to the reopen state on any incident update.

Why does my incident not change state when I acknowledge its associated alert?

When you acknowledge the alert, the incident only changes to the defined acknowledge state when the incident has not been touched yet. This means that the incident is in the state defined in incident detail of the alert action.

Why is an object still reopening my tickets when it is no longer monitored (deleted on SolarWinds side)?

When you delete a monitored object, its related objects (triggered alerts, interfaces...) are deleted. If an alert is in the triggered state at the time of deletion, the incident stays in the triggered state with no way to reset.

The incident will be cleaned up during nightly database maintenance.

To resolve the issue immediately, run the maintenance.

I want the integration to only create incidents and leave them alone afterward. How do I do this?

If you do not define any states in the Create ServiceNow Incident alert action, the incident will be created and receive notes when actions happen in the SolarWinds Platform, but its state will not be changed.

However, there will only be one incident at a time. Only when it is closed would a triggered alert create a new one.