Jira Service Management Support

Here’s an example of how a change request could look like, and how it progresses through the change management workflow. This should help you understand the changes you’ll be making to your projects.

Requesting a software upgrade – Jira Software

This example shows a request for a software upgrade of our Jira Software instance that lives as an asset in Jira Service Management.

What we're doing	What it looks like in Jira
Viewing an asset in Insight Let’s have a look at our Jira instance (asset) in Insight. It’s quite an old version and we want to get it upgraded to get new features, security updates, and all the other bug fixes. We’ll open a change request against it to upgrade it to the latest LTS release: 8.13.
What’s important here is some of the fields of our asset that will affect how our change request behaves: Importance (based on which our change will be assigned a proper risk) Owner (who needs to give a green light, because he’s the system admin responsible for this Jira instance) References to other assets: Server, License, Teams using it (just to see dependencies)
Creating a change request Let’s open a change request, and choose this Jira instance as an affected object.
Let’s fill in the fields explaining the change: Change type Change reason Urgency Impact
Let’s leave the new fields for plans empty right now. Who will be filling them out depends on the company process—usually it’s the change requestor, but let’s try including the whole team in it later.
Viewing the asset on the change request After the change request is created, details of our Jira instance are pulled into the request. Both you, and everyone interested, can view it. You can configure what exactly is displayed here…
…or just click it to view more details and dependencies.
The change request was also linked to our Jira instance in Insight. The system admin responsible for this instance will be alerted right away.
Viewing the effect of automation rules But, there’s more. Thanks to automation rules, Jira automatically: Defined the priority as High Defined the change risk as High This will help the approvers take necessary steps when approving this change—for example, they could move the date to a weekend and make sure that the teams using this Jira instance can work without it.
How did we do it? We added new automation rules to Jira Service Management. The ones used here: Use asset’s “Importance” to determine the change risk Use change request’s Impact / Urgency to assign a proper priority
In this case, automation rules don’t affect the change request that much, because Normal changes should go through all workflow steps and approvals – they usually don’t have established processes, yet are not emergencies, so we have time to review them.
But if it was an Emergency… that’s a different story. Thanks to automations, Emergency changes can bypass a few steps, so you can implement them right away instead of running around asking for permissions. It’s an Emergency after all.
Planning the change After our change request is transitioned to the Planning stage, the whole team can get together and collect all the necessary info. Implementation plan (how will we do it?) Test plan (how will we test it works?) Backout plan (how do we quickly roll back?) Just to make sure we know what we’re doing or can roll back if it turns out we don’t.
Approving the change by the asset’s owner With the plan ready, we can transition the change request to the Approving step where it will undergo the initial review. It would usually be done by change managers (fetched from a Jira user picker custom field) and someone responsible for this Jira instance—the right person at the right time.
Although you’d usually know who change managers are, you can have as many asset owners as you have assets. You don’t have to know who they are, because Jira will automatically assign them as approvers based on their relation to the asset. It will be a different owner for a different software or server, or maybe no owner if the asset isn’t that important.
How did we do it? We used approvers who are related to the Insight object. It won’t always be a fixed group of users – they will change based on the asset you select in the change request. Jira will: Check what’s the affected asset Look for approvers in its attributes Assign these people as approvers
Assessing the risk: CAB review After the initial review, the change is moved to the next approval step. Normal changes don’t have established processes so it’s good to properly assess them. Here the change is being assessed by the Change Advisory Board (CAB) that can include additional experts to reduce the risk and avoid any problems.
Implementing the change Once the change is approved, we can start implementing it. Let’s assume that all the teams have been informed and we can just upgrade this instance.
Optional: Changing the object’s status But, in case someone was wondering what’s going on with this Jira instance, starting the work on it triggered a status change. Jira is no longer Running, as we’re implementing the change. It’s In Service. This can be done through Insight post-functions added to the workflow. In this case, they change the object’s attribute when the change request is moved through a certain transition. This is not part of change management. If you’d like to use it, see Adding Insight functions to workflows in Jira.
Completing and closing the change Once Jira is upgraded and the work is done, we can complete the change, and see how everything is green again. When closing the change request, you can select the resolution: Change successful or Change failed.
What’s next? Once the change is complete, you can also view some Insight reports for your assets and changes that affected them.
For example, you can check how many issues were raised against your assets – how many incidents, problems, or changes. And if there’s too many… Well, this might just mean it’s time to buy a new asset.