Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

Incident ticketing integrations

Log in to subscribe to topics and get notified when content changes.

Incident ticketing integrations

An incident ticketing integration exchanges ticket data between your ServiceNow instance and a third-party system.

The advantages of an incident ticketing integration include the following items.

  • Establishing a ticket number that provides a unique key between systems.
  • Synchronizing the systems so that notifications can be triggered.
  • Transforming data for more uniform processing.
  • Tracking ticket activity for accurate reporting.

The level of data and the direction of the data that is exchanged categorizes the integration as uni-directional or bi-directional. In a uni-directional integration, a third-party system creates an incident ticket, passes data to your instance, and receives a ticket ID back as confirmation. In a bi-directional integration, incident data is exchanged, synchronized, and updated while data is sent between the systems.

For both integration types, a good practice is to implement a record-based log of the individual transactions for a given time period. If an outage occurs, a record-based log can tell you what data was exchanged, how it was transformed, when processing occurred, and if there were any errors. Record-based logs also allow you to run all the validation and transformation logic away from the main form, helping performance.

Before implementing your project, develop an integration plan in which all the implementation aspects and requirements are defined. Developing the integration plan helps you to review the current data, plan for future requirements, and identify and sequence project tasks.

Uni-directional incident ticketing integrations

Consider the requirements for an external, third-party system to create tickets. Define the data that must be sent to create a ticket, and what validation is required.

In this way, a standard web service interface can be created and published. This integration responds with a ticket number on success, or with a structured error message for validation failures and processing issues. An advantage of this implementation is that you can publish once and reuse for multiple applications, provided the additional integrations follow the integration specifications. A good practice is to create a dedicated account for each interface. Accounts provide accountability and report user statistics, and use a simple connectivity Point of Contact (POC).

Integration plan contents

  • Firewall requirements
  • Protocols to be used
  • Required middleware (for example, MS Biztalk)
  • Error messages
  • Validation rules

Example using basic authentication

This implementation responds to the third-party system with the ticket ID. The Import Set tables function as a staging area for your data.

Figure 1. Uni-directional ticketing integration using basic authentication
Uni-directional ticketing integration using basic authentication

Example using import sets

An implementation variation for the inbound path would be to use the Import Set Tables as interface tables. In this example, the Incident_Interface Table stores a history of data as it was received and before the data was transformed. The destination Incident Table could store a history of how the incident has changed over time and who changed it. The transform scripts would process the import set and the business rules would run on the target table.

Figure 2. Uni-directional ticketing integration using import sets
Uni-directional ticketing integration using import sets

Bi-directional incident ticketing integrations

A bi-directional integration exchanges data between your ServiceNow instance and a third-party system so that incident information is synchronized between the systems.

This integration is more complex than a uni-directional integration because it has the following requirements.
  • Comprehensive definitions of field mappings.
  • Standardization of where transformations take place: inbound, outbound, or both.
  • Consideration of the ownership of reference data.
  • How updates are performed on an ongoing basis.

Implement error handling. Include all these implementations in the integration plan.

While bi-directional implementations are developed on their own merits, you can develop a framework in the Now Platform that can be reused, for example, data driven validation rules.

Integration plan contents

  • Plan contents for all the aspects needed for a bi-directional integration.
  • State models for each organization.
  • Business rule definitions for keeping the tickets synchronized.
  • Requirements to store history of individual transactions. If this form of audit is a requirement, consider creating an interface table which is populated prior to creating and updating the destination table.
  • Transformation rules for all data elements.
  • Time lines for when reference data is transported to the information system. Include requirements to perform transformations before sending the data to and from each system.
  • Statement of reference data ownership at all stages.
  • Update schema definitions.

Example using import sets and web services

In this implementation, data authentication is done before insertion into the import set. Transform maps and scripts execute before the data reaches the Incident table. The Incident table is used to store the history of the incident records. For the outbound data path, the target table could trigger business rules before the data is queued in the outbound web service.

Figure 3. Bi-directional ticketing integration using import sets and web services
Bi-directional ticketing integration using import sets and web services

Example using import sets and the ECC queue

An implementation variation for the inbound path would be to use an import set table (in our example, the Incident Interface table) to store historical data. Data validation is also done now, and you can clear exceptions with processing or manual intervention. The Incident table uses a Third-Party Information table as a reference, and messages are generated based on business rules.

Implementing this type of integration involves a web-service component for third-party applications for inbound data. The ECC queue is recommended for outbound data.

Figure 4. Bi-directional ticketing integration using import sets and the ECC queue
Bi-directional ticketing integration using import sets and the ECC queue