Change management in Jira Service Management: a practical guide

To run change management in Jira Service Management, use the IT service management template on a Premium or Enterprise plan, classify each change as standard, normal, or emergency, enforce approval steps in the workflow, schedule work on the change calendar, and gate deployments through your CI/CD tool. Changes made by agents and automation follow the same process, with one addition: the record names the identity that acted and the person who owns it.

This guide covers IT change control, the part people usually mean by Jira change management. Atlassian defines a change as the addition, modification, or removal of anything that could affect services. That definition says nothing about who or what makes the change. One note on words: in Jira Service Management, "agent" often means a licensed person working in a service space. Here, "service agent" means that person, and "agent" means a Rovo agent or other software agent.

Which plan you need

Atlassian moved change management out of Free and Standard on October 16, 2024. Its plan change page lists these for Premium and Enterprise only:

• The change work category and change queues
• The change calendar
• Automated risk assessments
• CI/CD integrations for affected services and deployment tracking

On Free or Standard, existing service spaces keep their request types and work types, but the change section disappears, those requests move to the general queues, and some system automation may stop working. Atlassian's change pages now point to a Service Collection Premium or Enterprise plan for these features. Its pages on approval steps and calendar date fields apply to company-managed spaces only.

The three change types

Read the standard change flow in your own space before you rely on it. Atlassian's page says it looks for a change type of Standard, while the flow's name refers to low risk.

How to manage change requests in Jira Service Management

1. Start from the template. Atlassian recommends adapting the default change management workflow.
2. Raise the request. Create it directly, select a time on the change calendar, or let deployment tracking create it when a deployment starts.
3. Fill in what reviewers need. The default fields include change type, change reason, change risk, impact, urgency, approvers, CAB, and the planned and actual dates. A rollback plan is not in that list, so add one.
4. Review and approve. Use the two review stages, with approval steps switched on.
5. Schedule it. Put it on the calendar and check for conflicts.
6. Implement and close. Automation can fill in the actual dates, and a preset flow can transition the request when a deployment completes, fails, or is canceled.

Approvals: enforce them, because the default does not

The default workflow has two review stages: change manager or peer review, and change advisory board (CAB) review. By default, it does not force approvals at either one. Any service agent or admin can transition a work item through a review.

To close that gap, a Jira admin edits the workflow, selects the status, checks Include approval step, sets the number of approvers and the approver source, and publishes. The status needs both an approve and a decline transition. Approvers can come from a user field, a group, or the affected service. They do not need a Jira Service Management license, only customer access to the service space. The Approvals tab on the work item shows who approved or declined and when.

Change calendar and change windows

The change calendar shows scheduled changes across your service spaces by day, week, or month. You need to be a service agent to open it. Requests appear based on four date fields: planned start, planned end, actual start, and actual end. Atlassian's pages differ on which of them must be filled, so if a change is missing from the calendar, follow its setup page and check all four.

Change windows come in two kinds: maintenance windows and freeze windows. Atlassian describes both as visual indicators of when changes should or should not be scheduled. We found no page saying a freeze window blocks a change, so treat it as information unless you build the check yourself.

Risk assessment: three separate tools

• Preset automation. A preset flow updates the change type and risk when a change request is created.
• Risk insights panel. This panel shows conflicting changes, change windows, and open incidents on the same service. To see every risk, fill in affected services, affected Assets objects, and the planned dates.
• Risk assessment with Ops Expert. Ops Expert (formerly Rovo Ops) gives a Low, Medium, or High level, a written summary, and suggested mitigations. It does not approve or reject a change or enforce anything. It runs per user, so two approvers with different access can see different results. Atlassian says it is not HIPAA compliant.

Atlassian's pages differ on the status of that last one. One lists it for Premium and Enterprise with two risk categories. The Prevention Center page calls it an open early access program with four categories. Check both pages and your own settings before you write it into a process.

Deployment tracking and deployment gating

Deployment tracking creates change requests when your team starts deployments to selected services. Deployment gating goes further: it allows or prevents a deployment based on the status of the change request, and it needs tracking in place first.

Atlassian's pages differ on tools and plans. The gating setup page covers Bitbucket and Jenkins and says others are coming, while separate pages cover GitHub and GitLab. The main gating pages name Premium only. The GitHub gating page points to a Service Collection Premium or Enterprise plan, and the plan page lists CI/CD integrations for Premium and Enterprise without naming gating. Check the page for your tool, and if you are on Enterprise, confirm gating in your settings.

Changes made by agents and automation

A gate only sees deployments that go through the connected pipeline. An agent that edits a field or a configuration directly never meets it. Our guide to what change control needs before agents sets out eight controls. Here is how the main ones land in Jira Service Management, starting with identity, because every agent or flow acts through some account.

Which identity acted

Atlassian suggests Agent's account for most automation, and agents fall back to User's account if an admin has not set up Agent's account. An unattended agent on someone's account can reach everything that person can, and the record names them for what it does.

An identity is not an owner. Automation for Jira cannot answer for anything, so name a person for every agent, flow, and token. Okta stays the source of truth for the people who own and approve, and Guard adds controls on the Atlassian side. Service accounts cannot be provisioned from your identity provider, so your owner record has to make that link back to a person.

What the change record should capture

These are our recommendations, not Atlassian default fields.

• The acting identity: which agent, flow actor, or account
• The named owner of that identity
• The trigger: flow name and audit log ID, or the person who invoked the agent
• The affected services and Assets objects
• The change type, and which pre-approved category it falls under, if any
• The state before and after
• The approver, or the pre-approval it relied on
• The rollback plan, and who can run it without the agent

Copy the evidence into the record. Automation audit logs keep 90 days, and older entries cannot be recovered. The organization audit log shows up to 180 days and needs Guard or an Enterprise plan. Test this before rollout: have the agent make a change in a test space, then read the History tab the way you would during an incident.

Who approves

Atlassian's guidance draws the line: in chat, a person reviews an action before the agent takes it. In automation, nobody does. So approval has to sit in the workflow.

• Standard changes. A person approves the category once, in advance, and owns the list. For example: an agent may add a comment, and may not move a change past review.
• Normal changes. A person approves. We found no Atlassian page describing a Rovo agent as a named approver, so don't plan on it. Use Exclude approvers from so the people in fields you choose, such as an owner, cannot approve.
• Emergency changes. A person declares them. Don't give an agent the path where controls are thinnest.
• The automation path. Jira automation's Approve/Decline request action works regardless of how many approvers the workflow needs. Find every flow that uses it, name its owner, and treat it as a pre-approval.

Changing an agent's tools, access, or account is itself a change. If you add an agent to a workflow transition, it runs whenever anyone moves a work item to that status. Atlassian documents this for Jira, so test it in a service space first.

How it is rolled back

We found no Atlassian page describing a single action that undoes everything an agent or flow changed. Plan the reversal yourself, and make sure it does not depend on the agent.

1. Stop the actor. Disable the flow, remove the agent from the transition, or remove the agent's app access (Atlassian lists that page under Guard Premium). Deleting a service account removes its access and credentials. Write down who holds each of these.
2. Find the reach. The automation audit log shows each step of each run, and the History tab shows field edits and transitions.
3. Reverse it. Roll deployments back through the pipeline; Atlassian's emergency change definition covers this. Restore field values from the before state in the record.
4. Record it. Raise the rollback as its own linked change.

Limit the damage in advance. Atlassian's pages differ here. Its best practices page says an agent can only perform actions it has a tool for. Its accounts page says an automated agent on a User's account can still perform any action that user can, even with specific tools configured. So use Agent's account where you can, give the agent only the tools the task needs, and test what it can reach. Where it only produces text, set the Use agent step to Read actions only. Atlassian also says guardrail instructions are suggestions with no guarantee, so don't count them as a control.

The people side of a change

A change can pass every gate and still not stick. Tell each audience what is changing and why, train each role on its own work, have leaders use the new process visibly, and roll out in phases, starting with a pilot group. Frameworks such as ADKAR, Kotter's eight steps, Lewin's three stages, and the Prosci methodology give this work structure. Our change management programs cover this work.

Where to start

Check three things first: whether approval steps are on in your change workflow, which flows use the Approve/Decline request action, and which identity each agent runs under. Our service management work covers the workflows, approvals, and calendar, and we have moved teams off ServiceNow, Zendesk, PagerDuty, and on-premise systems.

Next step: talk to us about change control in Jira Service Management.