Network Management
ServiceNow Integration App 1.1.x Release Notes
Changes in ServiceNow Integration App 1.1.0: State field used instead of incident_state and Alert acknowledged only if the incident is changed in the ServiceNow UI. Changes in ServiceNow Integration App 1.1.1: Access roles no longer necessary were removed. Incident update synchronization to the Orion Platform for non-admin users was improved. Value lookup for incident reference fields using custom reference tables was improved.
First published date
Last published date
Overview
This article describes changes in the ServiceNow Integration App 1.1.x. The new versions provide the following updates:
ServiceNow Integration App 1.1.1
- Access roles no longer necessary were removed.
- Incident update synchronization to the Orion Platform for non-admin users was improved.
- Value lookup for incident reference fields using custom reference tables was improved.
ServiceNow Integration App 1.1.0
Product section
Resolution
ServiceNow Integration App 1.1.1
Removed access roles
The following roles were removed:- import_transformer
- mport_scheduler
Incident update synchronization to the Orion Platform for non-admin users
All users now correctly send updates to Orion when changing fields on an incident.
Value lookup for incident reference fields using custom reference tables
The workaround for a known ServiceNow limitation when using custom reference tables described in the Use reference fields section in ServiceNow help is no longer needed.
ServiceNow Integration App 1.1.0
Incident status: using state field instead of incident_state
The integration application now uses the state field instead of the incident_state field for communicating incident status between the Orion Platform and ServiceNow. Older versions of the Orion Platform are compatible with this integration app version.
SolarWinds ServiceNow Integration app does not support changing the incident_state field directly and mismatched state and incident_state choice lists. The changes were applied to conform with ServiceNow recommendations.
ServiceNow recommendations
-
Use the state field: In the incident workflow, many default business rules and data integrity policy checks rely on the default workflow and the state field. In the London release, some of those rules have been upgraded from UI only to apply to import sets and API scripts as well.
-
Do not have the incident_state field as the only field visible on incident forms. The incident_state field can only be changed by legacy ServiceNow business rules.
-
Keep the choice lists for state and incident_state fields on the incident table in sync. The incident_state field value of an incident is then kept in sync with the state field value using two out-of-the-box business rules: Copy State to Incident State (runs first) and Copy Incident State to State (runs last).
What happens if you keep using incident_state?
You can continue using incident_state, but the integration will only modify the state.
To see correct state values in the incident alert action setup, the state and incident_state choice lists must be the same. You also have to turn on the state synchronization business rules.
When could you be affected and how to resolve the issues?
-
If you turned off the state synchronization business rules and use incident_state on your Incident form.
-
If you do not have the state field choice list populated in the incident table.
This might happen if you have been upgrading your ServiceNow instance since the field inheritance was improved to allow separate choices for derived tables.
To resolve the situation, populate the choice list either from task.state or the incident_state field, as required.
Acknowledgment of alert from incidents
This change requires Orion Platform 2019.2 or later.
When a change is made on an incident using business rule, REST API update or other scripts, the associated Orion alert is no longer acknowledged.
It is only acknowledged when the change is done through a form in the ServiceNow UI.