Enable bidirectional integration with an external ticketing system in ITSI

Bidirectional ticketing lets you update and close episodes in IT Service Intelligence (ITSI) through an external ticketing system. A bidirectional integration exchanges data between your ITSI instance and a third-party system so that when you make an update to a ticket outside of ITSI, the episode information is also updated within ITSI.

ITSI leverages the Ticket Management data model in the Splunk Common Information Model (CIM) to normalize your data, using the same field names and event tags for equivalent events from your external ticketing system. See Ticket Management in The Splunk Common Information Model Add-on Manual.

This normalization enables you to create action rules for fields like priority, severity, and state without having to remember what they're called in your external system. See Overview of the Common Information Model in the Common Information Model Add-on Manual for an introduction to the data models and information about the fields and tags they use.

The following image shows how ITSI uses the CIM to update an episode.

ITSI currently only supports bidirectional ticket integration with ServiceNow. Download the Splunk Add-on for ServiceNow from Splunkbase. To configure the app and technical add-on, see Configure ServiceNow to integrate with the Splunk platform in the Splunk Add-on for ServiceNow manual.

Prerequisites

• Any required installations and configurations for your ticketing system.
  • Configure the app and technical add-on for ServiceNow. For instructions, see Configure ServiceNow to integrate with the Splunk platform.
  • Configure data inputs to collect data from your ServiceNow instance. For instructions, see Configure inputs for the Splunk Add-on for ServiceNow.
• The Splunk Common Information Model Add-on (CIM) must be installed.

1. Enable the Bidirectional Ticketing correlation search

ITSI ships with a correlation search that enables bidirectional ticketing. The correlation search queries your ticketing data model and sends an event to the itsi_tracked_alerts index each time an update is made. When sending these events to itsi_tracked_alerts, the correlation search also maps your system's specific fields to the CIM fields. For more information, see Ticket management in the Common Information Model Add-on Manual.

The Bidirectional Ticketing correlation search is disabled by default. To enable it, perform the following steps:

1. Click Configure > Correlation searches.
2. Toggle the Bidirectional Ticketing correlation search to enable it.

2. Configure action rules

Configure action rules for a notable event aggregation policy that sync the fields in Episode Review with the corresponding fields in your ticketing system. For example, if you already set up an aggregation policy to create incidents in ServiceNow, you must add action rules to update the fields in the ITSI episode when they change in ServiceNow.

If you're integrating with ServiceNow, see Supported arguments for incidents for a table of arguments that ServiceNow supports for incident updates.

Once you configure your aggregation policy action rules, any ServiceNow tickets linked through the Link Ticket action in Episode Review will have bidirectional ticketing enabled by default. Tickets don't need to be created through aggregation policy action rules for bidirectional ticketing to work. For more information, see Link a ticket in the Use Splunk IT Service Intelligence manual.

1. Navigate to Configure > Notable Event Aggregation Policies.
2. Open the existing policy that you use to create tickets in an external system.
3. Click the Action Rules tab.
4. Click Add Rule.
5. Click the If dropdown list and choose the option the <Ticketing System> incident associated with the episode has. The option only appears if you installed the CIM as well as the correct Splunk add-on for your ticketing system.
6. Configure a condition for when a field in an external linked ticket changes. See the following example:
   
   If state matches 6 (Resolved) then change status to Resolved for the episode.
   
   
7. Build out your aggregation policy so that each important change in your external ticketing system has an action rule that updates the corresponding episode in ITSI.
   For example, the action rules for state changes might look like this:

3. Test the integration

Test the integration to make sure you configured the fields correctly.

1. The next time the aggregation policy creates a ticket in your external ticketing system, update one of the field values for which you created an action rule. For example, change the ticket status from New to In Progress.
2. Go back to Episode Review in ITSI and confirm that the corresponding field was updated in the episode. Note that the field might take several minutes to update.

See also

• Create a ticket in ServiceNow or Remedy
• Create a custom aggregation policy in ITSI