Configuring bidirectional ticketing in ITSI
While many ITSI administrators configure actions to create tickets in external ticketing systems like ServiceNow or BMC Remedy, fewer take the additional step of configuring bidirectional communication. Bidirectional ticketing ensures that when an episode status changes in ITSI, the corresponding ticket updates automatically - and when a ticket status changes in your ticketing system, the episode updates in ITSI.
Without bidirectional ticketing, your ITSI episodes and external tickets can quickly fall out of sync:
- An engineer resolves a ticket in ServiceNow, but the episode remains open in ITSI
- An episode is closed in ITSI, but the ServiceNow ticket stays open
- For events you're not actively monitoring as a service in ITSI, you won't know a ticket has changed status until you manually check
Bidirectional ticketing eliminates this disconnect by keeping both systems synchronized automatically.
While this article uses ServiceNow as an example, the same process shown here applies to other ticketing systems:
- BMC Remedy: Similar process using the Splunk Add-on for BMC Remedy
- Splunk Infrastructure Monitoring: Integrate with Splunk infrastructure monitoring alerts
- Other systems: The same logical flow applies, but you won't have out-of-the-box add-ons and you'll need to build a structure similar to that shown in this article in your custom correlation searches and actions
This article is part of the The definitive guide to best practices for IT Service Intelligence, which provides essential guidelines to ensure optimal operations and an excellent end-user experience, helping you to unlock the full potential of ITSI.
Prerequisites
Before configuring bidirectional ticketing, you must have the following in place:
- Data ingestion method: A method to get data from your ticketing system into the Splunk platform—whether through a technology add-on (TA), HTTP Event Collector (HEC) endpoint, API polling, or another mechanism
- Data normalization: The incoming ticket data must be normalized against the Splunk Common Information Model (CIM)
- Common Information Model app: The Splunk CIM app must be installed
- Ticket creation capability: A method to create and update tickets in your ticketing system, typically through a TA like the Splunk Add-on for ServiceNow
- Service accounts: Accounts on the ticketing system with authorization to create, read, and update tickets
- Correlation searches: Configured correlation searches to detect ticket status changes
- Notable Event Aggregation Policies: NEAPs configured with appropriate actions for bidirectional updates
How to use Splunk software for this use case
Step 1: Configure the Splunk platform to work with your ticketing system
Install and configure the appropriate technology add-on for your ticketing system. For ServiceNow, this is the Splunk Add-on for ServiceNow. Ensure the add-on is configured with service account credentials that have permission to:
- Create new tickets
- Read existing tickets
- Update ticket status and fields
Step 2: Enable bidirectional communication
Enable the bidirectional ticketing correlation search that ships with ITSI. This correlation search monitors for status changes in your ticketing system and triggers updates in ITSI when changes are detected. Navigate to ITSI > Configuration > Correlation Searches and toggle Bidirectional Ticketing to Enabled.
Step 3: Create a ticket
In your notable event aggregation policy, create an action to open a ticket.
The initial ticket should be created whenever the criteria that you select are reached. For example, you might wish to create a ticket when an incident has exactly one item and is critical. An example configuration is shown below.
Step 4: Add different rules to update tickets and episodes
Many administrators only configure the "create a ticket" action and consider the setup complete. However, bidirectional ticketing requires additional rules to handle status synchronization in both directions. This step is particularly important for event analytics scenarios where you're not actively monitoring a service in ITSI, since you won't know the ticket has changed until you receive an update from ServiceNow.
You need to configure action rules to match the different conditions that can occur in both systems. While the specific conditions depend on your ticketing system and workflow, common scenarios include:
- New episode created → Create new ticket
- Episode severity increased → Update ticket priority
- Episode acknowledged → Update ticket status
- Episode resolved → Resolve ticket
- Episode broken → Close ticket
- Ticket status changed → Update episode status
- Ticket resolved → Resolve episode
- Ticket reopened → Reopen episode
Each of these conditions requires a corresponding rule in your notable event aggregation policy configuration. Although the dialog for both creating and updating tickets is the same, you can use different fields to implement different variations. An example configuration is shown below.
The final action configuration should look like the example shown in the screenshot below.
Additional resources
For more information on using bidirectional ticketing, see Splunk Help.
These resources might also help you understand and implement this guidance: