How to Sync SLA Information from ServiceNow to Jira

[#1]

Teams working on different software platforms often have data to share. A software integration can make this very simple and save you a good amount of time, especially if you need to exchange information regularly.

Sometimes, however, things are more complicated. Non-standard information needs an advanced solution to share successfully.

One such use case is for teams working on ServiceNow (SNOW) who need to share Service Level Agreement (SLA) information with development teams working in Jira. 

The Use Case

We have a SNOW instance that holds SLA information, which is associated with incidents. When an SLA is breached, that can trigger an incident. 

Our other team is working on Jira. We already use an integration to share incidents with them. However, the integration can’t deal with SLAs by default.

We need to fix this, so that the Jira team can get all relevant SLA information.

The Specifics

• SLAs need to be copied from ServiceNow to Jira.
• SLAs have multiple subfields that need to be copied.
• Not all SLA data is stored on the associated incident record.

The Challenges

• A custom class needs to be created for Jira to handle the specialized SLA records with their subfields.
• The integration potentially needs to map multiple SLAs to each record, while allowing for there not being any in some cases.
• To sync the SLA names, we need to get additional data from the contract_sla table, which requires custom code.

The Integration Solution: Exalate

Exalate can synchronize items bi-directionally between multiple platforms. It works with ServiceNow, Jira, Zendesk, Azure Devops, Salesforce, GitHub and more.

Exalate exchanges most types of information by default, but for some advanced cases you need to go a little further. In the next section, you’ll learn how to configure your Exalate integration to exchange SLAs automatically.

Implementation with Exalate

First you need to connect your Jira and ServiceNow. That will give you a standard synchronization, sharing most fields automatically.

However, getting the SLAs to sync requires some custom code.

Take a look at your connection in the list, and click edit to bring up the sync rules screen. This is where you add the new code. You’ll need to do this on both sides of the connection.

Starting with ServiceNow, you need to add the following to the ‘outgoing sync’ section on SNOW.

OUTGOING ON SNOW 

class SlaRecord {

    String name
    String breach_time
    String stage 
    String linkValue
}

 

if (entity.tableName == "incident") {

    replica.key = entity.key
    replica.summary = entity.short_description
    replica.description = entity.description
    replica.attachments = entity.attachments
    replica.comments = entity.comments

    replica.state = entity.state

    def RelatedSlaRecords = []
    def limitResult = 20

    // lookup all related SLA records

    def request = "/api/now/table/task_sla?sysparm_query=task.number=${entity.key}&sysparm_limit=${limitResult}"
    def response = httpClient.get(request)

    if (!response || !response.result) return null

    // For each SLA record, lookup corresponding value in contract_sla table
    // and collect all the data required within the RelatedSlaRecords array

    response.result.each {

         SlaRecord temp = new SlaRecord()
         temp.breach_time = it.planned_end_time
         temp.stage = it.stage
         temp.linkValue = it.sla.value

         def slaRecord = httpClient.get("/api/now/table/contract_sla/${it.sla.value}")

         temp.name = slaRecord.result.sys_name
         RelatedSlaRecords.add(temp)

     }

     replica.slaResults = RelatedSlaRecords

}

A key part of this code is the following line:

   def request = "/api/now/table/task_sla?sysparm_query=task.number=${entity.key}&sysparm_limit=${limitResult}"
   def response = httpClient.get(request)

This gets a custom object which you can use to get the data you want to send to Jira.

Next, with Jira, you need to add the following code to your incoming sync section. This code is simpler. Here you're taking the incoming slaResults object, unpacking it, and copying the data into a custom field named SLA Info.

INCOMING ON JIRA

issue.customFields."SLA Info".value = ""

for(int i=0; i<replica.slaResults?.size; i++){

    issue.customFields."SLA Info".value += "Name: ${replica.slaResults[i].name} \n Breach Time: _${replica.slaResults[i].breach_time} \n State: ${replica.slaResults[i].stage} \n\n"
}

Once this code is in place, add some SLAs to a created ticket and click to ‘Exalate’ it, you should find it moving from SNOW to Jira with the SLA records included.

From now on, other tickets that match your rules should be synchronized automatically, with SLAs intact.

Conclusion

Synchronizing the platforms you work on is a great way to boost your productivity. Thanks to Exalate’s flexibility, you are not limited to default options when sharing data.

Its powerful scripting puts you in full control of the data you share, letting you adjust non-standard fields to fit with other platforms. This way your teams don’t miss out on the information they need. 

By the way, I am co-hosting a live webinar with Nviso (October 20, 4 PM CET) on how integrating with your customers can make communication easier and smoother. 

The webinar content: 

• What is "deep ticket integration"?
• How service providers use it for Access Management, Security Response Efficiency, and workflows?
• An actual use case of automatic ticket creation from XSOAR to Jira 
• Learn how integration has helped scale collaboration with customers
• Q&A with the speakers 

You can register here if you’re interested.