How to integrate Jira with Ivanti Service Manager: Part 2 – Joining and Tracking Fields

IT Operations and DevOps teams often use separate platforms for tracking their work. Integrating these separate platforms together provides values. Teams are more efficient in keeping statuses in sync. This blog series provides an example of how to integrate these two platforms. For our ITSM platform we use Ivanti Service Manager (ISM). For our DevOps platform we use Jira Software. In Part 1, we began the steps to integrate ISM and Jira. In Part 2 we take the next step. By the end of this series, you will have the foundation that can be used for developing your integration between your Ivanti Service Manager (ISM) and Jira Software platforms.

In the previous blog, we set up the service accounts required to communicate between Jira and ISM. Along with the service accounts, we generated the API tokens needed for authentication for each service account in the other system. The service accounts provide us with two advantages: we can easily track what issues/releases are created in the other system, and they allow us to avoid an infinite loop of creating tickets and releases between the systems. Once the service accounts and API tokens were created, we used PostMan to validate successful connections to both ISM and Jira.

If you have not already read Part 1 it can be found here:

In this blog, we will be reviewing all the modifications needed in Jira and ISM to accurately reflect the tickets in the opposite systems. This will include ISM custom fields such as the Jira Project Name, the issue type, status, and issue number. We will also need to create custom fields in Jira to map to ISM, such as RecID and SprintRecId.

Before we get into the creation of custom fields, here is a brief overview of the entire lab we are building over the five parts of this series.


The integration between ISM and Jira allows for seamless communication. It automatically creates a corresponding ticket for the reported issue in the opposite platform. Integrating the two systems eliminates potential human error and saves time. The synchronized reflection of data between the two systems makes it easy for stakeholders such as developers, administrators, and auditors to track software issues in ISM throughout the software development lifecycle as they change statuses in Jira.

JIRA issues are represented as releases in ISM. Attachments providing insight into the issues can be added from either end; issues can be organized into sprints from JIRA to support agile or scrum software development.

In Part 2, we will be creating the fields required to track corresponding Issues and Releases in Jira and ISM.

The process diagram below outlines the workflow for the two systems and the final prototype deployment:

Figure 1

Lab Overview

To support this blog, I have provisioned the following lab components:

  • Ivanti Service Manager-Cloud

ISM is an IT service management software: a help-desk application for submitting IT service requests, reporting issues with applications or equipment, and getting status updates.

  • JIRA Software-Cloud

JIRA is an issue and project tracker used by development teams for use as an organized to-do list that follows each task through development, testing, and resolution.

  • PostMan

PostMan is a tool used for API development. It offers the ability to collaborate, and easily build or dissect APIs.

Joining/Tracking between ISM and Jira

Mapping fields between ISM Releases and Jira Issues will take some additional custom fields. For example, an issue’s status or type in Jira is something that should be reflected in the corresponding ISM Release. By adding these fields, a release in ISM will more thoroughly reflect an issue in Jira and vice versa.

ISM Custom Fields

We are using the Release object to represent sprints and two issue types: bugs and enhancements. It is likely that you will have other release types and fields unrelated to Jira, so we will use the following naming convention: LAB_JIRA<NameofField>.

To track issues, we will need the release business object to store the following new fields:

Field Name



Display Name: JIRA Status

Field Type: Text

Text Length: Variable, max 32


Display Name: JIRA Issue Type

Field Type: Text

Text Length: Variable, max 32


Display Name: JIRA Priority

Field Type: Text

Text Length: Variable, max 32


Display Name: JIRA Issue Number

Field Type: Text

Text Length: Variable, max 32


Display Name: JIRA Project Name

Field Type: Text

Text Length: Variable, max 50


Display Name: JIRA Sprint Name

Field Type: Text

Text Length: Variable, max 32


Display Name: JIRA Release Created by ISM

Field Type: Text

Text Length: Variable, max 32

Validated: Checked

Pick List Name: YesNo


Display Name: JIRA Attachment Content URL

Field Type: Text

Text Length: Variable, max 200


Display Name: JIRA Attachment Filename

Field Type: Text

Text Length: Variable, max 200

Figure 2

We also will be working with attachments. These are the fields that will need to be added to the attachment business object.

Field Name



Display Name: JIRA Attachment Type

Field Type: Text

Text Length: Variable, max 32


Display Name: JIRA Parent Object ID

Field Type: Text

Text Length: Variable, max 32

Figure 3

Creating a Field

You will need to add all the fields from Figure 2 to the release business object and the fields from Figure 3 to the attachment business object. I’ll walk you through the first one, and you can repeat the steps to add the rest.

1. From the Configuration Console, click on Build > Business Objects in the left-hand navigation.

Figure 4

2. We are working with the Release business object so click on Release to view the object.

Figure 5

3. Select the Fields tab. You will see a list of the default fields.

Figure 6

4. Click Add New…

Figure 7

5. Select the Text field type. The system will display the Setting Field Details workspace.

6. Enter information for the new field in the fields based on the details in Figure 2 or 3.