Blog · 1 October 2026

Jira change management template: fields, flow, and repeats

A good Jira change management template is three things: a Change work type with a short set of fields (summary, change type, risk, planned start and end, approvers), a workflow that routes each change type to the right amount of review, and a list of standard changes your team does not need to argue about every time. Jira Service Management ships most of the first two in its IT service management template. This guide shows what to keep, what to add, and how to handle the part the template leaves to you: the standard changes that come round on a calendar, like monthly patching or a quarterly access review.

Statements about Jira Service Management are as of October 2026, from Atlassian's own documentation. Atlassian now calls an issue a work item and a project a space. This guide uses both words, because most admins still say issue and project.

What the change management template gives you #

If your team uses Jira Service Management, start from the IT service management space template rather than an empty space. It comes with a Change work type, a change management workflow, a change calendar and a set of default fields. Atlassian's field reference lists them, and the ones that matter for a template are these:

Two sentences in that reference are worth knowing before you customise anything. The first is about required fields:

For your change management deployment pipelines to work, only the Summary and Description fields should be set to Required for the Change work type.

So resist the urge to make every field mandatory on create. Use the workflow to ask for risk and approvers at the review step instead. The second is about the calendar. Each of the four date fields carries the note:

This field is required for change requests to appear on the change calendar.

A change without a planned start and end is invisible on the calendar, which is the one place a reviewer looks to spot two changes colliding in the same window.

Build your own change request template, step by step #

The steps below assume a company-managed service space. Team-managed spaces offer the same ideas with fewer controls.

1. Create the space from the IT service management template, or open the one you already have.
2. Check the Change work type's fields. In Space settings, open the work types and confirm the fields in the table above are on the create screen and the view screen. Remove what your team will never fill in. An empty field on every change trains people to skip fields.
3. Write the description as a template. Put headings straight into the description field's default text: What is changing, Why, Test plan, Rollback plan, Communication. A reviewer can then see at a glance which section somebody left empty.
4. Set up the request type your requesters use to ask for a change, and show only the fields a requester can answer. Risk and CAB are for the reviewers, so leave them off the portal form.
5. Decide who approves what. Add approvers per request type, or a CAB field for the board, and add the approval step to the workflow.
6. Turn on the standard change shortcut (next section) so low-risk changes skip the board.
7. Raise a test change of each type and walk it through to Closed, checking it lands on the change calendar on the right dates.

If your organisation keeps a written change plan for bigger changes, Atlassian also publishes a Confluence change management template. That is a document for planning one large change. The Jira template above is the record every change, large or small, goes through.

Route each change type to the right amount of review #

The Change type field is what keeps change management from becoming a queue nobody can get through. Atlassian's ITSM guide defines the three types:

Atlassian's own wording for the first row:

Standard changes are low-risk, commonly repeated, and pre-approved.

Jira Service Management turns that definition into a rule you can switch on. The IT service space template includes an automation template named When a low risk change management request is in review → move request to approved. Its documentation says it looks at change requests whose Change type is Standard, and:

It transitions these through the Peer review / Change manager approval stage to the Planning stage.

You find it under Space settings, then Automation. Atlassian notes the page applies to company-managed spaces only. Switch it on before you go live, or every standard change waits in a review step nobody needs to perform.

The part the template leaves out: standard changes that come back on a schedule #

Here is where most change processes leak. A lot of standard changes are not raised by anyone. They are due: the second-Tuesday patch run, the monthly backup restore test, the quarterly firewall rule review, the certificate that expires every year. The template handles them well once a change request exists. Nothing in it creates the request.

So somebody has to remember. When they do, the change is raised in a hurry with half the description copied from last month. When they don't, the work happens anyway (somebody patches the servers) and the change record never exists, which is exactly the gap an auditor asks about.

The fix is to have the request created for you, on the schedule, already filled in from the template. There are three ways to do it in Jira Cloud.

Option 1: a recurring reminder and a cloned request #

Keep last month's change request as a model, and clone it each cycle from a calendar reminder. It costs nothing and works for a handful of changes. It also depends on the one person with the reminder, and a clone carries last month's dates, comments and links unless somebody tidies them every time. See bulk cloning in Jira for what a clone does and does not copy.

Option 2: Jira Automation's scheduled trigger #

Jira Automation can create a work item on a schedule with the Scheduled trigger and a Create work item action, and it works inside a service space. Fill Change type with Standard, set the planned dates with smart values, and the auto-approve rule above takes it straight to Planning. The things to plan for:

• A cron expression for anything beyond "every N days". "Second Tuesday of the month" needs one, and Jira cron expressions has the syntax and the traps.
• Every run spends automation usage. A rule that creates a change and its subtasks spends several steps each time it fires. Jira Automation pricing shows what each plan includes and what happens when the allowance runs out.
• No working-day calendar. A schedule that lands on a public holiday creates the change anyway, with a planned start nobody will be in for.

Option 3: a scheduling app in the team's Jira project #

Recurring Work Items for Jira creates a work item in a Jira project on a schedule you write once, with no cron and no automation usage. For recurring operational work, it covers what the other two options leave to a person:

• Monthly on a weekday ordinal. "Every month on the second Tuesday" is a choice in the editor, and a preview lists the next five dates before you save.
• A working-day calendar per project, with your weekend and a holiday list. Each rule decides what happens on a non-working day: run anyway, move to the next or previous working day, or skip that occurrence.
• The template filled in. Summary, description, assignee, priority, labels, a due date and the custom fields on the project's create screen, with tokens so the title reads Patch run, October 2026 rather than the same text every month.
• The checklist as subtasks. Up to ten subtasks under each request, one per step of the runbook, each with its own assignee. Jira subtask templates compares this with the other ways to get the same subtasks every time.
• A run history that names the work item each run created, or the reason it did not create one.

It works one project at a time, and a project has to be switched on before anything in it runs. Try it on the project that will hold the changes before you move a whole calendar of standard changes onto it.

Which option fits #

When the manual way is enough #

Most normal and emergency changes should stay manual. They are raised because something new is happening, and the value of the template is that it makes the requester think about risk and rollback. Automating their creation would skip the thinking.

Scheduling only earns its keep for the standard changes that recur on a known calendar. If your team has two of those, a reminder is fine. Once it is ten, spread across patching, backups, access reviews and certificates, the reminder becomes the weak link in a process whose whole point is that nothing happens unrecorded.

A checklist for your change management template #

• A Change work type with only Summary and Description required.
• A description pre-filled with the sections every change must answer, including rollback.
• Planned start and end on every change, so the change calendar shows it.
• Change type on the create form, with standard changes auto-approved.
• Approvers or a CAB field, used at review rather than on create.
• A written list of your standard changes, and for each recurring one, something that raises it on schedule.

For other recurring work in Jira, see Jira recurring tasks, which compares the same three approaches for any kind of repeating ticket.