What this template is for
Change management is where the cost of a missing field is highest. A bug ticket without reproduction steps is annoying. A change ticket without a rollback plan is a future outage.
This template encodes the ITIL change-management contract into Jira across two layers:
- Required fields on the change create screen - risk class, blast radius, rollback plan, validation plan, maintenance window, CAB approval. None of these are optional, because none of them are optional in practice; they just become tribal knowledge that disappears when the implementer leaves the team. Configure them on the project’s Create Issue screen and make the critical ones required.
- Sub-tasks STM creates on every change ticket - pre-change notification, runbook freshness check, CAB step, execution, validation, rollback path, post-change documentation. An STM On Create Issue Executor scoped to issue type Change creates the full checklist so the implementer can’t accidentally skip the steps that matter under pressure.
When to use it
Use this template for any change to production infrastructure or production-affecting configuration. This includes deploys outside the regular pipeline, database migrations, network changes, third-party integration cutovers, and DNS changes.
Code deploys through your normal CI/CD pipeline typically do not need a change ticket per deploy - the pipeline itself is a pre-approved standard change. Use this template for the changes the pipeline doesn’t cover.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Upgrade payments DB primary to Postgres 16 | Yes |
Change Type | Standard / Normal / Emergency | Yes |
Risk Class | Low / Medium / High | Yes |
Description | What is changing and why | Yes |
Blast Radius (custom) | All checkout traffic; 3 downstream services | Yes |
Rollback Plan (custom) | Failover to standby; documented in runbook RB-118 | Yes |
Implementation Plan (custom) | Numbered steps with timing | Yes |
Validation Plan (custom) | Smoke tests, key metrics to watch, success criteria | Yes |
Maintenance Window | 2026-05-22 02:00-04:00 UTC | Yes |
CAB Approval (custom) | Approved 2026-05-20 by @cab-chair | No |
Implementer | @oncall-platform | No |
Reviewer | @platform-tech-lead | No |
Linked Incident/s | Optional; for changes prompted by an incident | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Pre-change: notify affected stakeholders and post in #change-calendar
- Pre-change: confirm rollback runbook is up to date and tested
- CAB review and approval (skip for standard changes)
- Execute implementation plan during the maintenance window
- Run validation plan and confirm success criteria met
- If validation fails: execute rollback plan and reschedule
- Post-change: update CMDB / config docs / runbooks
- Post-change: close the change ticket with outcome and any deviations from plan
Common questions
What's the difference between a standard, normal, and emergency change in Jira?
Standard changes are pre-approved low-risk repeatable changes (e.g. routine deploys) and skip CAB. Normal changes are non-routine and require CAB approval before the maintenance window. Emergency changes are unscheduled responses to an incident and use an abbreviated approval path. The template's Change Type field drives which sub-tasks apply.
Why does a rollback plan need to be a required field on a Jira change?
Because 'we'll figure it out if something breaks' is how outages turn into prolonged outages. A written rollback plan forces the implementer to think through reversibility before the window starts, and gives the on-call a runbook to follow under stress if the change goes wrong.
How should risk class be assigned to a change request?
Risk is a function of blast radius (how many systems and users are affected) and reversibility (how quickly and cleanly you can roll back). A change that touches every checkout request and takes 20 minutes to roll back is high risk even if the code change is trivial.
Can a Jira change template enforce CAB approval before implementation?
Yes - but enforcement comes from the Jira workflow, not from STM. Add a workflow transition condition that blocks the In Implementation status unless the CAB Approval field is populated. STM's role is to auto-create the change's sub-task checklist (pre-change notify, runbook check, execute, validate, rollback-if-needed, post-change docs) via an On Create Issue Executor so the implementer has the playbook in front of them.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →