Incident Priority Matrix Servicenow

 admin
UrgencyA measure of how long it will be until an Incident has a significant Impact on the organization. For example, a high Impact Incident may have low Urgency, if the Impact will not affect the organization until the end of the financial year.
Critical:Incident causes immediate and significant disruption affecting life-safety, business transaction-critical, teaching-related services while in use.

No workaround available.

High: Incident causes immediate and significant disruption but not affecting life, safety, business transaction-critical or teaching-related services while in use.

No workaround available.

Moderate:Incident will cause some disruption in the near term.

Workaround may or may not be available.

Low: Work not affected.
ImpactA measure of the effect of an Incident on organizational processes. Impact measures the number of clients potentially affected by an Incident.Campus:Charles River or BUMC or BOTHP1TechStatus & TechWeb with possible broadcast mail or SendWordNowP1TechStatus & TechWeb with possible broadcast mail or SendWordNowP2TechWebP2Ticket Notification
Multiple Groups:Academic Unit, Administrative Unit, Building or StoreP1TechWebP2TechWebP2TechWebP3Ticket Notification
Group: Department, Floor, Instructional EnvironmentP2Ticket NotificationP2Ticket NotificationP3Ticket NotificationP3Ticket Notification
Individual: Client, Room, OfficeP2Ticket NotificationP3Ticket NotificationP3Ticket NotificationP4Ticket Notification

Communication procedures in blue

What is Incident Management? When it comes to Incident Management, you may already know that a task's priority can be determined with the equation 'Impact x Urgency'. But how do we decide in the real world what counts towards these factors? Essentially, there are four things to consider, which will help us map out a priority matrix. OOTB Low-Low does equate to a priority level of '5-planning' which I've found some clients elect to hide/not use within their matrix. This matrix is a great representative example of the right level of simplicity for an organization just starting out within ITSM space. Here is a '4x4' impact urgency matrix.

Service Level Targets – Incidents

Servicenow
PriorityInitial Assignment*Resolution
P115 mins2 hours
P21 business hour4 business hours
P32 business hours1 business day
P44 business hours3 business days

Service Level Targets – Service Requests

PriorityInitial Assignment*Resolution
P130 mins4 hours
P22 business hours4 business hours
P34 business hours2 business days
P41 business dayBy scheduled date
* Target time for initial assignment to an individual or a group (assigning to an accountable analyst changes the ticket’s status from “New” to “Assigned”, or to “Unassigned” if escalating to another assignment group).
Note: “Hours” = real time (24/7) while “business hours/days” = Monday through Friday, 9 AM – 5 PM

PDF Documentation PowerPacks Customer Portal Contact Documentation

Overview

This section describes the ScienceLogic integration with the ServiceNow Incident Management Module. This integration automatically logs, de-duplicates, correlates, updates, and appends ServiceNow Incidents, reducing the amount of time to resolve critical service issues. This integration covers the entire Incident life cycle, providing a bi-directional integration between SL1 events and ServiceNow Incidents, while providing a granular view into both the event and the associated Incident.

This section covers the following topics:

Use the following checklists to help you set up Incident Sync between SL1 and ServiceNow.

Checklist 1: Initial Installation and Configuration

This checklist covers how to install and configure the different elements used for Incident Sync:

  1. Install the ServiceNow Base Pack PowerPack in SL1
  2. Validate network communications
  3. Align the new configuration file with the following integration applications:
  • 'Create or Update ServiceNow Incident from SL1 Event'
  • 'Sync Incident State from ServiceNow to SL1 Event'
  • 'Update ServiceNow Incident when SL1 Event is Acknowledged'
  • 'Update ServiceNow Incident when SL1 Event is Cleared'

Checklist 2: Configure the Run Book Automation

This checklist covers how to set up the Run Book Automation to run Incident Sync:

  1. Enable the following Run Book Action Policies:
  • 'ServiceNow: Add/Update Incident'
  • 'ServiceNow: Event Acknowledged'
  • 'ServiceNow: Event Cleared'

You must install the 'ScienceLogic SL1: CMDB & Incident Automation' application on the ServiceNow instance to enable the Integration Service ServiceNow SyncPack. The 'ScienceLogic SL1: CMDB & Incident Automation' application is also known as the 'Scoped Application'.

Integration Service instances running version 2.0.0 or later of the ServiceNow integration applications are not backwards-compatible with the previous ServiceNow update sets or with SyncServer. After you install the 'ScienceLogic SL1: CMDB & Incident Automation' application on your ServiceNow instance, you need to upgrade your ServiceNow integration applications to version 2.0.0 or later on all Integration Service instances. The 'ScienceLogic SL1: CMDB & Incident Automation' application is also not backwards-compatible with SyncServer. This change cannot be reverted.

Before you can use version 2.0.0 or later of the Integration Service ServiceNow SyncPack, you must first request the 'ScienceLogic SL1: CMDB & Incident Automation' application from the ServiceNow Store and then install it.

To request and install the application:

  1. Go to the ServiceNow Store at https://store.servicenow.com and search for 'ScienceLogic SL1'.
  2. Select the 'ScienceLogic SL1: CMDB & Incident Automation' application. The detail page for the application appears.
  3. Click . You must have an HI Service Account to request this application.

NOTE: The ServiceNow SyncPack version 2.0.0 or later requires version 1.0.7 or later of the 'ScienceLogic SL1: CMDB & Incident Automation' application.

  1. After the request is approved, log in to ServiceNow as an administrator and navigate to Application Manager (System Applications > Applications).
  2. Click in the menu header.
  3. Click the button for the 'ScienceLogic SL1: CMDB & Incident Automation' application. The installation is complete when the button changes to .

A SyncPack contains all of the necessary steps, integration applications, and configurations needed for a release. After you install the 'ScienceLogic SL1: CMDB & Incident Automation' application, you need to upload version 2.0.0 or later of the Integration Service: ServiceNow SyncPack.

After you finish this process, all of the integration applications on your Integration Service will be updated to version 2.0.0 or later.

The complete ServiceNow SyncPack component will be added into the Integration Service platform in a future release. For version 2.x.x, the SyncPack is only a .tar file.

To update your integration applications to this version:

  1. Download the .tgz archive file containing the integration applications from the ScienceLogic Customer Portal. Save the file on your Integration Service instance.
  2. Run the following command to extract or 'untar' the files:

tar -xvf ServiceNow_SyncPack-2.x.x.tgz

  1. On your Integration Service instance, navigate to the new ServiceNow_SyncPack directory.
  2. Run the following command twice to ensure the upload of all integration applications that depend on other integration applications:

iscli -usf util/ -p password

  1. To upload the 2.x.x steps, run the following command:

iscli -usf steps/ -p password

  1. To upload the 2.x.x integration applications, run the following command twice to ensure the upload of all integration applications that depend on other integration applications:

iscli -uaf apps/ -p password

  1. To upload the 2.x.x configurations, run the following command:

iscli -ucf configs/ -p password

You might need to individually upload the 'Sync Devices from SL1 to ServiceNow' integration application a second time after the bulk upload to ensure that the application picks up the correct application variable formatting in the user interface.

For the ScienceLogic ServiceNow Incident Sync integration solution, you must install the most recent version of the ServiceNow Base Pack PowerPack.

NOTE: If you are upgrading from SyncServer, you must disable the old SyncServer Run Book Actions and Run Book Automation policies before installing the new ServiceNow Base Pack PowerPack.

To install the ServiceNow Base Pack PowerPack:

  1. Log in to SL1 as an administrator, then go to the PowerPack Manager page (System > Manage > PowerPacks).
  2. Click the button and select Import PowerPack.
  3. Click the button and navigate to the ServiceNow Base Pack PowerPack file.
  1. Select the PowerPack file and click . The PowerPack Installer modal page displays a list of the PowerPack contents.
  2. Click the button. After the installation is complete, the ServiceNow Base Pack PowerPack appears on the PowerPack Manager page.

By default, installing a new version of a PowerPack overwrites all content in that PowerPack that has already been installed on the target system. You can use the Enable Selective PowerPack Field Protection setting in the Behavior Settings page (System > Settings > Behavior) to prevent new PowerPacks from overwriting local changes for some commonly customized fields. For more information, see the section on Global Settings.

For more information about installing and using the ServiceNow Base Pack PowerPack, see Using SL1 to Monitor ServiceNow.

Event Data Flow: Integration Service to ServiceNow

The following chart and steps illustrate the event data flow from the Integration Service to a ServiceNow instance:

  1. Workers are subscribed to the Integration Service task queue.
  2. When a new event to be synced is placed in the Integration Service task queue, it is assigned and pushed to a worker.
  3. The worker processes and transforms the necessary SL1 event data into a ServiceNow incident and POSTs the incident to the ServiceNow endpoint.
  • If the resulting status code matches the expected status code for the request, the original message is acknowledged and removed from the queue.
  • If the worker crashes while processing the event, the queue senses the unexpected disconnect, and the same event message is re-delivered to a new worker.

NOTE: The above results are performed through the 'late acknowledgment' of tasks. With this setting enabled, an Integration Service worker will not remove a message from the queue until the message has been fully processed by the worker. This setting can be enabled or disabled with the environment variable 'task_acks_late'.

  1. If ServiceNow responds with an unexpected status code when POSTing the incident, the message will be placed back in the queue with specified re-try parameters.

NOTE: You can configure re-try parameters on a per-task basis. You may want to manually alter your re-try parameters for tasks depending on the action the task is taking. The configuration of retries includes the maximum number of times a task is retried after consistently failing, and the delay length between retries.

Event Data Flow: SL1 to Integration Service

The following chart and steps illustrate the event data flow from SL1 to the Integration Service:

  1. Through a Run Book Automation, SL1 identifies an event that should be synced to ServiceNow.
  2. A Run Book Action executes a POST action to the Integration Service API to let the Integration Service know that an integration should be run to sync the event.
  • If the Run Book Action is successful and the POST responds with a 200, then the event data is stored in the Integration Service queue for syncing.
  • If the POST does not respond with a 200, then the Run Book Action inserts the missed event into a table in the SL1 database so that it can be retrieved later.
  1. In parallel, a scheduled Integration Service event continuously checks the SL1 database for any missed events. If any missed events are found, they will be pulled from the database and inserted into the Integration Service queue.

NOTE: The Integration Service queue is persistently saved to disk, so if the Integration Service stops unexpectedly, any events that existed in the queue prior to the failure will still exist in the queue after the Integration Service is running again.

  1. Missed are not removed from the SL1 database until after they are inserted into the Integration Service queue.

All communication between SL1 and ServiceNow is done through TCP port 443. To allow communication between SL1 and ServiceNow, the SL1Database Server, Data Collector, or All-In-One Appliance must have external access to the ServiceNow instance. No inbound TCP ports are required to be open to the SL1 server. Outbound communication may use NAT or be direct.

All firewall session-limiting policies must be disabled. If firewall session-limiting policies are enabled, HTTPS requests might be dropped by the firewall, resulting in data loss. Check with your security or firewall administrator to make sure there are no session limiting policies on TCP port 443 for your SL1 servers.

Checking DNS

Because ServiceNow is a cloud-based service, DNS must be configured on all SL1 servers that communicate with your ServiceNow instance.

ServiceNow instances are generally named as: your-instance.service-now.com, where your-instance is the name of your ServiceNow server. The examples below use mycompany.service-now.com. Your instance name will be unique to your subscription.

To validate that your SL1 server has proper DNS name resolution configured, test network connectivity and name resolution using the nmap command, which is available from the command line of any SL1 server:

nmap -sT -p 443 mycompany.service-now.com

If the test was successful, you will see a message similar to the following:

Starting Nmap 5.51 ( http://nmap.org ) at 2013-11-12 20:22 UTC

Nmap scan report for mycompany.service-now.com (199.91.136.100)

Priority

Host is up (0.067s latency).

PORT STATE SERVICE

443/tcp open https

If domain name resolution fails, you will see a message similar to:

Failed to resolve given hostname/IP: mycompany.service-now.com.

Checking HTTPS and JSON

You can administer a simple test to determine if the ServiceNow JSON Plug-in web service is configured and operating using the Basic Authentication method on your ServiceNow instance. To do so, run the following command from the ScienceLogic Central Database or All-In-One Appliance:

In the example below, replace the admin:admin username and password key/value pair with your ServiceNow administrator username and password and mycompany.service-now.com with your ServiceNow instance name.

curl --location -vu admin:admin -H 'Accept: application/json' -H 'Content-Type: application/json'

'https://mycompany.service-now.com/api/now/table/incident'

If not successful, the following message appears:

HTTP/1.1 401 Unauthorized

If successful, a JSON encoded string starting with the 'result' variable appears:

Now

{'result':[{'upon_approval':','location':'1083361cc611227501b682158cabf646',….

HTTP Codes

HTTP codes are necessary for identifying specific problems. The following table lists typical HTTP codes that might occur when testing the ServiceNow JSON Web Service.

CodeDefinition
401Unauthorized. Check that the username and password are correct and properly formatted.
403Forbidden. ServiceNow understood the request, but either the URL is incorrect, or the user account does not have permission to see the requested object.
404The ServiceNow server has not found anything matching the requested URL. Check to make sure there is data in the target table.
200Success.
201Success. Data is posted.

For more information about the ServiceNow JSON Web Service and the Table API, see http://wiki.servicenow.com/index.php?title=Table_API. If you continue to have problems, please contact either ScienceLogic or ServiceNow customer support.

For best practice and security, create a dedicated ServiceNow account that has restricted access to only the groups, access control lists (ACLs), and roles needed for ScienceLogic incident management.

To create a ServiceNow Account for ScienceLogic Incident management:

  1. In ServiceNow, go to the Groups page (User Administration > Groups).
  2. Click . A New record page appears.
  1. In the New record page, type the group name and any additional information. Name is the only required field.
  1. Right-click the Group bar and click Save to save the record.
  1. At the bottom of the Group form, select the tab and click .
  1. Search for x_sclo_scilogic.Admin and move it to the Roles List column using the arrow buttons.
  1. Click . Your Group now has an assigned Role:

Creating a ServiceNow User

To create a ServiceNow Account for ScienceLogic Incident management:

  1. In ServiceNow, go to the Users page (User Administration > Users).
  2. Click .
  1. In the New record page, complete the following fields:
  • User ID. Type a user ID.
  • First Name. Type the user's first name.
  • Last Name. Type the user's last name.
  • Password. Type a password.
  • Active. Select this checkbox.
  • Web Service Access Only. Select this checkbox.
  • Time Zone. Select GMT.
  • Date Format. Select System (yyyy-MM-dd).
  1. Right-click the header and click Save to save the user.
  1. Select the tab at the bottom of the record.
  1. Find the group you created previously and move the group to the right-hand column using the arrow buttons. Click .

After the user has been added to the group, you should see their Roles and Groups in their record:

NOTE: See the Create a User page of the ServiceNow Product Documentation for more information on creating a ServiceNow user account.

To configure Incident Sync, you will need to create a new configuration object or file in the Integration Service user interface and align that configuration object to the relevant integration applications that are triggered by the Run Book Actions in SL1. The configuration object supplies the login credentials to execute the steps for the integration applications.

Creating a Configuration Object

To create a new configuration object:

  1. In the Integration Service user interface, go to the tab.
  1. Click the plus icon (). The Create a new configuration pane appears:
  1. Complete the following fields:
  • Version. Version of the configuration object.
  • Author. User or organization that created the configuration object.
  • Friendly Name. Name of the configuration object.
  • Description. A brief description of the configuration object.
  1. In the Configuration Data field, specify the variable definitions:

For example, you could add the following JSON code to the Configuration Data field:

[

{

'encrypted': false,

'name': 'em7_host',

'value': '10.2.11.42'

},

{

'encrypted': false,

'name': 'em7_user',

'value': 'em7admin'

},

{

'encrypted': true,

'name': 'em7_password',

'value': '+dqGJe1NwTyvdaO2EizTWjJ2uj2C1wzBzgNqVhpdTHA='

}

]

  1. When creating a configuration variable, note the syntax:
  • The configuration file is surrounded by square brackets.
  • Each variable definition is surrounded by curly braces.
  • Each key name is surrounded by double-quotes and followed by a colon, while each value is surrounded by double-quotes and followed by a comma.
  • Each key:value pair in the definition is separated with a comma after the closing curly brace. The last key:value pair should not include a comma.
  1. To create a configuration variable, define the following keys:
  • encrypted. Specifies whether the value will appear in plain text or encrypted in this JSON file. If you set this to 'true', when the value is uploaded, the Integration Service encrypts the value of the variable. The plain text value cannot be retrieved again by an end user. The encryption key is unique to each Integration Service system. The value is followed by a comma.
  • name. Specifies the name of the configuration file, without the JSON suffix. This value appears in the user interface. The value is surrounded by double-quotes and followed by a comma.
  • value. Specifies the value to assign to the variable. The value is surrounded by double-quotes and followed by a comma.
  1. Repeat steps 5 and 6 for each configuration variable.
  2. Click the button.

NOTE: In a step, you can include the config. prefix with a variable to tell the Integration Service system to look in a configuration object to resolve the variable.

Aligning a Configuration Object

To align the configuration object with the relevant integration applications:

  1. Log in to the Integration Service user interface with the username isadmin and the password that you set during installation.
  2. For the following integration applications, you must 'align' the configuration object to run with that application:
  • 'Create or Update ServiceNow Incident from SL1 Event'
  • 'Update ServiceNow Incident when SL1 Event is Acknowledged'
  • 'Update ServiceNow Incident when SL1 Event is Cleared'
  • 'Sync Incident State from ServiceNow to SL1 Event'

The 'Sync Incident State from ServiceNow to SL1 Event' integration application is the only application for Incident Sync that can be run manually or scheduled. The other three applications should only be triggered by Run Book Automations.

  1. Open the first integration application and click the button. The Configurations pane for that application appears:
  1. From the Configurations drop-down, select the configuration object you created and click to align that configuration with the integration application.

NOTE: The values for eventDetails and the other parameters that appear in the Configuration pane with a padlock icon () are populated either by the configuration object you align with the integration application in step 4, or by the Run Book Action. Do not modify these values. If you encounter an error, make sure your Run Book Action is configured properly.

  1. Repeat steps 3-4 for all of the integration applications listed in step 2.

NOTE: The 'Sync Incident State from ServiceNow to SL1 Event' integration application does not have an associated Run Book Action that triggers Incident Sync. You must schedule this application to run every minute, or to a time suitable for your requirements. You can use a cron job to trigger this schedule, or you can use the Integration Service user interface to schedule the application.

You can configure Run Book Automation to ensure that whenever SL1 detects an event, a corresponding incident is created or updated in ServiceNow.

SL1 features three Run Book Action policies that facilitate this process:

  • ServiceNow: Add/Update Incident
  • ServiceNow: Event Acknowledged
  • ServiceNow: Event Cleared

Each Run Book Action policy calls a single action in SL1. Ensure that the integration application points to the relevant SL1 system and ServiceNow instance. The action then calls an integration application on the Integration Service that determines the workflow to execute.

Events in SL1 frequently occur and resolve due to fluctuations in the network and other changing conditions. However, the Run Book Action policies above use a de-duplication algorithm whereby only a single open ServiceNow incident exists per device. Therefore, if a device already has an existing ServiceNow incident, the following updates are made to the ServiceNow incident record:

  • The 'Work Notes' activity log in the incident record is updated with information about the secondary event(s).
  • If a secondary event is of a higher severity than the event that originally created the ServiceNow incident, then the Impact, Urgency, and Priority fields are updated automatically in the ServiceNow incident record. If the secondary event is of a lesser severity, those fields are not updated.
  • If an event is cleared in SL1 and then later reoccurs before the incident has been 'Closed' in ServiceNow, then the subsequent events appear in the original ServiceNow incident record for that device. If an incident record has been 'Closed,' then ServiceNow will create a new incident record when a cleared event reoccurs in SL1.
  • By default, if an event is acknowledged in SL1, the ServiceNow incident record will be updated with the work notes and the acknowledging user. Clearing a ScienceLogic event will move the ServiceNow incident record state to 'Resolved'. If all ScienceLogic events associated with a ServiceNow incident record are clear, the ServiceNow incident record will, by default, move to a 'Resolved' state.

You can edit the Run Book Action Snippet code to adjust the behavior for changing states when an SL1 event is acknowledged or cleared.

To configure SL1 to communicate with ServiceNow, you must first create a SOAP/XML credential. This credential allows the Run Book Automation scripts and the Dynamic Applications in the ServiceNow Base Pack PowerPack to connect with your ServiceNow instance. An example SOAP/XML credential that you can edit for your own use is included in the ServiceNow Base Pack PowerPack.

To create a SOAP/XML credential to access the Integration Service:

Incident Priority Matrix Service Now Login

  1. Go to the Credential Management page (System > Manage > Credentials).
  2. Locate the ServiceNow RBA - Example credential, then click its wrench icon (). The Edit SOAP/XML Credential page appears:
  1. Complete the following fields:
  • Profile Name. Type a new name for the ServiceNow credential.
  • Content Encoding. Make sure text/xml is selected.
  • Method. Make sure POST is selected.
  • HTTP Version. Select HTTP/1.1.
  • URL. Type the URL for your Integration Service instance.
  • HTTP Auth User. Type the username of your Integration Service instance.
  • HTTP Auth Password. Type the password of your Integration Service instance.
  • Timeout. Type '5'.
  1. Click .
  2. When the confirmation message appears, click .

For more information about using the ServiceNow Base Pack PowerPack, see Using SL1 to Monitor ServiceNow.

The Run Book Automation policy is initially aligned to an example credential. You will need to align the previously created credential to the Run Book Action.

Enabling Run Book Action Policies

The ServiceNow Run Book Action policies are disabled on SL1 by default. To enable them, you must enable and align the ServiceNow credential to each policy.

To enable Run Book Action policies:

  1. Log in to your ScienceLogic Administration Portal as an administrator, and then go to the Action Policy Manager page (Registry > Run Book > Actions).
  2. Locate the ServiceNow: Add/Update/Clear Incident policy and click its wrench icon ().
  1. The Action Policy Editor page appears. Complete the following fields:
  • Action State. Select Enabled.
  • Snippet Credential. Select the credential that you created in the section Creating a ServiceNow Credential.
  • Snippet Code. If you want to customize the Run Book Action script, make changes as necessary. For more information, see the section Customizing Run Book Action Policies.
  1. Click .

Customizing Run Book Action Policies

You can customize several default values that are embedded into the SL1 Run Book Action snippets for ServiceNow.

For example, the CORRELATION_TYPE is a value you can use to correlate an SL1 event with a ServiceNow incident. For the CORRELATION_TYPE, which is also called the 'Correlation ID', you can choose six different ways in which an incident can be created. The default setting is CORRELATION_TYPE=5, which means this Run Book Action correlates all events by Device ID and Event Policy ID, and if the event matches and the state is active, the Action updates the existing incident. The Action creates a new incident if the event does not match by Device ID and Event Policy. As a result, the CORRELATION_TYPE value helps determine which events get rolled up under an incident.

To edit Run Book Action snippets:

  1. Log in to your SL1Administration Portal as an administrator and go to the Action Policy Manager page (Registry > Run Book > Actions).
  2. Click the wrench icon () of the Run Book Action you want to edit. The Policy Editor modal page appears:
  1. Edit the Snippet Code as necessary, using the information that follows as a guide. When you are finished, click .

ScienceLogic Run Book Action snippets are written in Python. In the event of a syntax error, the policies will no longer run. As a result, you must ensure that all edits adhere to Python standards.

True and False options are case-sensitive and must not contain quotes.

Customizing the 'Add/Update/Clear Incident' Run Book Action Script

NOTE: Previous SyncServer users had three separate Run Book Action scripts for add/update, acknowledge, and clear. These have been rolled into a single Run Book Action in the Integration Service, but there are still three Run Book policies.

You can customize the following items in the 'ServiceNow: Add/Update/Clear Incident' Run Book Action snippet code:

  • CORRELATION_TYPE = 5
  • This is an integer value and possible values are 1, 2, 3, 4, 5, or 6. Default value is 5.
  • All RBA Scripts should use the same value, otherwise correlation will fail.
  • 1 = Correlate all duplicate incidents by SL1 ID only.
  • 2 = Correlate all duplicate incidents by Event Policy ID only.
  • 3 = Correlate all duplicate incidents by device ID only.
  • 4 = Correlate all duplicate incidents by Interface ID only. NOTE: This correlation requires that the ScienceLogic event has an interface aligned. If there is no interface aligned to the event, the returned Interface ID will be 0.
  • 5 = Correlate all duplicate incidents by device ID and Event Policy ID.
  • 6 = Correlate all duplicate incidents by device ID, Event Policy ID, and Event Sub Entity ID.
  • NEW_SNOW_STATE = 1
  • This is an integer value and possible values are 1, 2, 3, 6, 7, or 8. Default value is 1.
  • 1 = Incident state is 'New'.
  • 2 = Incident state is 'In Progress'.
  • 3 = Incident state is 'On Hold'.
  • 6 = Incident state is 'Resolved'.
  • 7 = Incident state is 'Closed'.
  • 8 = Incident state is 'Canceled'.
  • ACK_SNOW_STATE =
  • This is an integer value and possible values are 1, 2, 3, 6, 7, or 8. There is no default value.
  • 1 = Incident state is 'New'.
  • 2 = Incident state is 'In Progress'.
  • 3 = Incident state is 'On Hold'.
  • 6 = Incident state is 'Resolved'.
  • 7 = Incident state is 'Closed'.
  • 8 = Incident state is 'Canceled'.
  • CLEAR_SNOW_STATE = 6
  • This is an integer value and possible values are 1, 2, 3, 6, 7, or 8. Default value is 6.
  • 1 = Incident state is 'New'.
  • 2 = Incident state is 'In Progress'.
  • 3 = Incident state is 'On Hold'.
  • 6 = Incident state is 'Resolved'.
  • 7 = Incident state is 'Closed'.
  • 8 = Incident state is 'Canceled'.
  • You can use the following Passthrough Dictionaries to pass hard-coded mappings through the Integration Service to ServiceNow.
  • NEW_PASSTHROUGH = {}
  • ACK_PASSTHROUGH = {}
  • CLEAR_PASSTHROUGH = {}
  • A hard-coded value for the variable EM7_ID must be set to uniquely identify the ScienceLogic instance. This can be used for domain separation.
  • EM7_ID = 'EM71'
  • You can set the assignment group that New, Acknowledged, and Cleared incidents are mapped to. To disable this feature, ensure no values are set. Once an incident is created, the assignment group value will not be changed by the Run Book Action. To assign an assignment group, set the variable value to the sys_id of the ServiceNow Assignment Group.
  • NEW_ASSIGNMENT_GROUP
  • ACK_ASSIGNMENT_GROUP
  • CLEAR_ASSIGNMENT_GROUP

Customizing Logging on Run Book Action Script

You can customize the following logging-related items in the ServiceNow Run Book Action snippet code:

  • logfile = /data/tmp/ServiceNow_add_update_clear_incident.log
  • Location for Logging output.
  • Will be created if it does not exist.
  • Will be appended with each RBA job.
  • Is case-sensitive.
  • do_debug_logging = True
  • True is on, False is off.
  • Is case-sensitive.
  • For troubleshooting, these can be enabled or changed.
  • Writes logs to /data/tmp/servicenow_rba.log.

Enabling Run Book Automation Policies

After you have enabled the ServiceNow Run Book Action policies, you must enable the corresponding ServiceNow Run Book Automation policies.

Itil Severity Matrix

To enable the ServiceNow Run Book Automation policies:

Incident Priority Matrix Servicenow
  1. Log in to your SL1Administration Portal as an administrator, and then go to the Automation Policy Manager page (Registry > Run Book > Automation).
  2. Locate the ServiceNow: Add/Update Incident policy and click its wrench icon ().
  1. The Automation Policy Editor page appears. Update the following fields:
  • Policy State. Select Enabled.
  • Policy Priority. Select High to ensure that this Integration Service automation policy is added to the top of the queue.
  • Available Actions. If it is not already selected, select the corresponding ServiceNow Run Book Action policy.

By default, the automation policy will create ServiceNow incidents for all devices. You can limit the devices affected by making changes to the Organization, Severity, Match Logic, Aligned Devices, and/or Aligned Events fields.

ScienceLogic highly recommends that you do not make changes to the Policy Type, Repeat Time, or Align With fields or the And event is NOT acknowledged setting.

  1. Click .
  2. Repeat steps 2-4 for the ServiceNow: Event Acknowledged and ServiceNow: Event Cleared Run Book Automation policies.

To view SL1-created incidents in ServiceNow, go to the Incidents page (Incident > Open) in the ServiceNow application. All SL1 incidents use the event message from the SL1 event console as the incident description in ServiceNow.

For more information about ServiceNow incident management, see https://wiki.servicenow.com/index.php?title=Incident_Management.

SL1 and ServiceNow use slightly different methods for designating the severity or priority of an event or incident. To handle the conversion, a transformation script that translates SL1 event severity into the following ServiceNow Impact, Urgency, and Priority fields automatically deploys with the ScienceLogic Scoped Application:

SL1ServiceNow
Event SeverityImpactUrgencyPriority
CriticalHighHighCritical
MajorHighMediumHigh
MinorMediumMediumModerate
NoticeLowMediumLow

If a secondary event for the same SL1 device occurs and it has a higher severity level than the existing ServiceNow incident, the ServiceNow incident automatically updates to indicate the severity change. If a secondary event has a lower severity level, then the severity is not updated.

When SL1 Run Book Automation creates a ServiceNow incident, the 'Working Notes' activity log is updated each time an action occurs with the incident. The following example illustrates that the initial event that created the ServiceNow incident was of Major severity. Minutes later, a Critical event occurred and the incident updated accordingly. Minutes later, the event was acknowledged in SL1 and the incident state was then set to 'active,' letting ServiceNow users know that the problem is being researched.

Incident topology suppression is used when ServiceNow incidents that have been synced with SL1 devices occur on devices that have a parent/child relationship. If you choose to enable incident topology suppression in SL1, child events synced with ServiceNow incidents do not appear in the SL1Event Console as separate events. Instead, the child events are nested under the parent event.

To enable incident topology suppression:

  1. In SL1, navigate to the Event Policy Manager page (Registry > Events > Event Manager) and click the button. The Event Policy Editor modal appears:
  1. On the tab, update the following fields:
  • Event Source: Select API.
  • Operational State: Select Enabled.
  • Event Severity: Select Critical as the severity of the event.
  • Policy Name. Type the name of the event. Can be any combination of alphanumeric characters, up to 48 characters in length
  • Event Message. Type the message that will appear when this event occurs.
  1. Click the tab.
  1. On the tab, update the following fields:
  • Detection Weight. Select 20 - Last. If two event definitions are very similar, the weight field specifies the order in which SL1 should match messages against the similar event definitions. The event definition with the lowest weight will be matched first. This field is most useful for events that use expression matching. Options range from 0 (first) - 20 (last).
  • Match Logic. Select Regex Match. Specifies whether SL1should process the First Match String field and Second Match String as regular expressions or as simple text matches. Because you selected Regex Match, you cannot define a 'match all' expression by leaving the First Match String and Second Match String fields empty.
  • Use Message-match. Select this option. If SL1 has generated an event and then a second log message or alert matches the same event policy for the same entity, SL1 will not generate a second event, but will increase the count value for the original event. This behavior will occur only if the log messages or alerts contain the same message.
  • First Regular Expression. Type 'CRITICAL' as the string used to correlate the event with a log message.
  • Topology Suppression. Select Both. If this event occurs on a parent device, it behaves as a suppressing event. If this event occurs on a child device, it behaves as a suppressible event.
  1. Click and close the Event Policy Editor modal.
  2. Next, go to the Device Groups page (Registry > Device Groups) and click the button. A Device Group Editor page appears:
  1. Complete the following fields, and leave the default settings for the remaining fields:
  • Template Name. Specify the name of the new device group.
  • Force Child Visibility. Select 'No'.
  • Visibility. Select Config Policies/Bulk Edit to let you configure all the devices in the new device group using a device template.
  1. Click the button and then click the button in the Dynamic Rules pane to add dynamic rules to the new device group. The Device Group Rule Editor modal page appears:
  1. In the Active Selectors pane, select Device Name.
  2. Optionally, in the Selector Definitions pane, type an asterisk (*) in the Device Name field. Using the * includes all devices by Device Name. In the Matched Devices pane, a list of all devices appears.
  3. Click to close the modal page.
  4. On the Device Group Editor modal page, click and close the page.
  1. Next, create a Device Group Template that will disable Event Masking for all devices in the new Device Group. Click the building blocks icon () for the new device group. A Device Template Editor page appears:
  1. Because all of the fields are disabled (grayed-out) by default, click the Event Mask field name to enable the field. Use the default setting of Disabled.
  2. Click and click on the Device Template Editor page.
  3. Next, turn off the Trigger on Child Rollup option on the 'ServiceNow: Add/Update Incident' Run Book Automation. Go to the Automation Policy Manager page (Registry > Run Book > Automation) and click the wrench icon () for the 'ServiceNow: Add/Update Incident' Run Book Automation. The Automation Policy Editor page appears:
  1. Make sure the Trigger on Child Rollup option is not selected and click . Close the Automation Policy Editor page.

Both ServiceNow and SL1 provide mechanisms for hyperlinking to multiple active events and incidents. This section describes those processes.

ServiceNow Hyperlinking

In ServiceNow, each incident created by SL1 includes a ScienceLogic URL field with a hyperlink back to the SL1 event:

By default, the ScienceLogic URL field does not appear on the incident form. To add the link:

  1. In SL1, go to the Behavior Settings page (System > Settings > Behavior).
  2. In the Interface URL field, enter the URL of your ScienceLogic system.

The ScienceLogic URL link is dynamic to the actively aligned SL1 event. Because of this, the link might change multiple times during the life cycle of a ServiceNow incident.

For instance, if the event is cleared or resolved in SL1, the ScienceLogic URL is removed because the event no longer exists in the SL1 Event Console. If a duplicate or correlated event is later detected and aligned with the ServiceNow incident, the link will be updated to match the new SL1 event.

Each time SL1 creates or changes an incident in ServiceNow, data is inserted into a temporary import table on the ServiceNow system. This table displays all inbound data from SL1 and is a useful tool to determine what data is being sent and imported. The incident import table is created automatically when you install the ScienceLogic Scoped Application.

To view the data and the status of the import process, in ServiceNow, go to the ScienceLogic Events page (ScienceLogic > Import Tables > Incident Import):

You can view a complete audit of all import data and transforms by going to the Transform Histories page (System Import Sets > Advanced > Transform History):

By default, when SL1 triggers an event, it is sent to ServiceNow through the Integration Service. The following mappings are currently in place for SL1 events to Incidents in ServiceNow:

SL1 EventSNOW Priority
CriticalP2
MajorP3
MinorP4

A transformation script that translates the SL1 event severity into the ServiceNow Impact, Urgency, and Priority fields automatically deploys with the ScienceLogic Scoped Application.

By default, the Priority field is read-only and must be set by selecting the Impact and Urgency values.

Priority is calculated according to the following data lookup rules:

ImpactUrgencyPriority
1 - High1 - High1 - Critical
1 - High2 - Medium2 - High
1 - High3 - Low3 - Moderate
2 - Medium1 - High2 - High
2 - Medium2 - Medium3 - Moderate
2 - Medium3 - Low4 - Low
3 - Low1 - High3 - Moderate
3 - Low2 - Medium4 - Low
3 - Low3 - Low5 - Planning

To edit the transform script:

  1. Go to your ServiceNow instance and search for 'Transform Map'.
  2. Under Administration > Transform Maps, select the 'ScienceLogic Incident' map.
  1. In the Transform Scripts tab, open the OnBefore transform script with the Order of 200.
  1. Edit the Impact and Urgency in the following code, as needed:

//Setting impact and urgency off Event Severity on the import table.

switch(source.u_event_severity.toString()){

case '1': //Sciencelogic Event (Critical)

impact = 1;

urgency = 2;

break;

case '2': //Sciencelogic Event (High)

impact = 2;

urgency = 2;

break;

case '3': //Sciencelogic Event (Minor)

impact = 2;

urgency = 3;

break;

case '4': //Sciencelogic Event (Notice)

impact = 3;

urgency = 3;

break;

default:

break;

}

For example, if you want to raise a P1 from a Critical event, you would set it as impact=1 and urgency=1.

Alternatively, using the defaults provided in the SL1 transform script, you can add a business rule which automatically changes the Priority to a custom preset.

If you require additional mandatory fields to be filled out to resolve an incident, you can add those fields to the transform map. For example, if you require four mandatory fields in the ServiceNow Incident—Assignment Group, IT Service, Service Component, and Description—to be filled out before that incident can be resolved in SL1, you would perform the following steps:

To add an assignment group:

  1. Navigate to User Administration > Groups.
  2. Select the assignment group you want to add. Right-click on the gray task bar at the top and elect Copy sys_id.
  1. Go to the 'ServiceNow: Add/Update/Clear Incident' run book action in SL1. Edit the run book action to add your sys_id:

NEW_ASSIGNMENT_GROUP= '

ACK_ASSIGNMENT_GROUP= '

CLEAR_ASSIGNMENT_GROUP= 'ADD SYS_ID HERE'

Add the sys_id to assign the group to Clear, Ack, or trigger a New event which is sent to ServiceNow.

The IT Service, Service Component, and Description fields in our example must be filled in before an Incident can be closed. To do this, changes must be made in the transform maps that are provided in the form of update sets from ScienceLogic.

To add the Description field:

  1. In your ServiceNow instance, search for 'transform map' in the left-hand menu. Click Transform Maps.
  2. In the list of transform maps, search for 'ScienceLogic' in the field above the Name column.

Itil Prioritization Matrix

  1. Open the 'ScienceLogic Incident' map:
  1. The Field Maps table at the bottom of the page allows you to edit or create mappings from the ScienceLogic Incident Import table to the ServiceNow Incident table. Click to create a new field mapping.
  2. The Source table field should contain the ScienceLogic Incident Import and the Target table should include the ServiceNow Incident table:
  1. To create a new mapping to copy the contents of the Short description field to the Description field, select Short description from the Source field drop-down menu.
  2. In the Target field drop-down menu, select Description.
  3. Click Update to save your changes.
Matrix

The IT Service and Service Component fields in our example are set in the Transform Script in the 'ScienceLogic Event' transform map. To set the fields:

  1. Make sure you have the sys_id for the target fields. These can be found in ServiceNow. If a field contains a magnifying glass, it will require a sys_id. If a field has a drop-down, then type in the field you wish to apply from the drop-down. In the case of our example, the sys_ids of the two fields are required.
  2. In your ServiceNow instance, navigate to the Transform Maps table and select 'ScienceLogic Event'.
  1. In the ScienceLogic Event transform map page, click the Transform Script tab and open the 'onAfter' script.
  1. Add the following under the '//Update target record when the Event was cleared from Sciencelogic' text:

sl_INT.(target field) = '[sys_id of the source field]'; //(IT service field)

sl_INT.(target field) = '[sys_id of the source field]'; //(Service component)

Servicenow Impact Urgency Priority

  1. To find the target field, make a temporary mapping to see what the target field is. This mapping can be deleted once you know the target field.

Incident Priority Matrix Service Now Free

  1. Click to save your changes. The selected fields will be added into an Incident on closure.