Jira Issue Templates: Types, Examples, and How to Create Them

Jira has no built-in issue template feature. Not on Cloud, not on Data Center. This surprises people, partly because Jira does ship project templates, so “Jira has templates” is true in a way that does not help when what you want is a repeatable work item.

This guide covers what teams mean by issue templates, the types that exist, worked examples, the three native workarounds and exactly where each one breaks, and what to look for if you decide a dedicated tool is worth it.

Issue templates vs project templates

Worth clearing up first, because it wastes a lot of people’s time:

• Project templates (space templates on Jira Cloud) create a whole new project with a preset workflow, issue types, and screens. Jira ships plenty of these: Scrum, Kanban, service management, and so on.
• Issue templates pre-fill a single work item: its description, fields, labels, components, sub-tasks. Jira does not ship these.

If a colleague tells you Jira has templates, they are almost certainly talking about the first kind.

The four types of issue template

Teams use the word “template” for four different things, and the differences matter when you evaluate options.

1. Description templates

The description field is pre-filled with a structure: headings, prompts, a checklist. Everything else about the item is filled in by hand.

Good for: bug reports, where the goal is making sure people include the steps to reproduce.

2. Full item templates

The description plus the fields: issue type, priority, labels, components, assignee, custom fields, due date offsets.

Good for: requests that always route the same way, such as an access request that must carry the right component and approver.

3. Hierarchy templates

A parent with its sub-tasks, or an epic with its child items, all created in one action.

Good for: onboarding, releases, incident response, anything that is really a checklist of work rather than one task. This is the type native Jira handles worst.

4. Triggered templates

A template that fires automatically when something happens: a transition, a field change, an item being created in a particular project.

Good for: processes where forgetting to apply the template is the actual failure mode. If a security review must be created whenever a change request moves to Approved, you do not want that to depend on someone remembering.

Worked examples

The shape of a good template is easier to see than to describe. A few common ones:

• Bug report wants steps to reproduce, expected versus actual, environment, and severity. Without prompts, you get “it’s broken” and a two-day round trip.
• User story wants the “as a / I want / so that” frame plus acceptance criteria, so estimation is possible.
• Incident response is a hierarchy template: the incident item plus sub-tasks for triage, comms, mitigation, and the follow-up postmortem.
• Release checklist is a hierarchy template where the value is that nobody skips a step at 5pm on a Friday.
• Employee onboarding (IT) creates the accounts, hardware, and access sub-tasks together, because the failure mode is remembering four of the five.
• Change request carries the risk assessment, rollback plan, and approver fields that a change advisory board will ask for anyway.

There are around sixty worked examples in the Jira templates library, covering engineering, DevOps, ITSM, security, product, hiring, and customer success.

The three native workarounds, and where each breaks

1. Cloning an existing item

Find a well-formed item, clone it, edit the copy.

Works for: a one-off repeat of something you did recently.

Breaks because: it copies everything, including the things you did not want (links, attachments, the old assignee, comments in some configurations). There is no canonical version, so the “template” drifts as people clone from clones. And when the process changes, there is nothing to update: the next person clones an item that predates the change.

2. Team-managed project description defaults

In a team-managed project you can set a default description per issue type, which new items inherit.

Works for: a lightweight description prompt in a single team-managed project.

Breaks because: it is description only, one per issue type, and unavailable in company-managed projects, which is where most larger organizations run. No fields, no sub-tasks, no conditions.

3. Automation rules

Build a rule that creates items with pre-filled fields, optionally with sub-tasks.

Works for: genuinely automated creation, and it is the strongest native option.

Breaks because: each variation is a separate rule. Ten request types means ten rules to build and maintain, and the content lives inside rule configuration where it is hard to review and easy to break. Rule execution limits apply on Cloud plans. Most importantly, it is inside out: automation is designed to react to events, not to give someone a template to pick from when they are creating work by hand.

What a real template system needs

If you evaluate tools, these are the properties that separate one that holds up from one that becomes a second maintenance problem:

• A canonical template that is edited in one place, so updating the process updates the template.
• Hierarchy support: parents with sub-tasks, epics with children, created in a single action.
• Field coverage beyond the description, including custom fields.
• Variables, so a template can adapt to context rather than needing a near-duplicate for each variation.
• Triggers, so templates apply on transitions or field changes and do not rely on memory.
• Bulk application, so a template can be applied across a set of existing items, usually via JQL.
• Permissions that respect Jira’s, so a template cannot create work somewhere the user could not create it themselves.

STM Issue Templates covers this set: cascading templates, executors that trigger on transitions or field changes, and bulk create and update across JQL queries, on both Cloud and Data Center.

Setting up your first template

Whichever route you take, the sequence that works is the same:

1. Pick the process that hurts most. Usually the one where work arrives incomplete and gets bounced back. Do not start by templating everything.
2. Find three recent real examples of that work and look at what the good ones had that the bad ones did not. That difference is your template.
3. Write the structure, not the content. Prompts and headings, not placeholder prose people will leave in. Lorem ipsum in a template will reach production eventually.
4. Decide what is mandatory. Every required field is friction, and too much friction sends people back to creating blank items.
5. Decide how it gets applied: chosen by hand, or triggered automatically. If forgetting is the failure mode, trigger it.
6. Test with someone who did not build it. The gaps are obvious to them and invisible to you.
7. Review it after a month. Templates that are never revised become the thing people work around.

Frequently asked questions

Does Jira have a native issue template feature? No. Neither Jira Cloud nor Jira Data Center has a built-in issue template feature. You can clone an existing item, and team-managed projects let you set a default description per issue type, but neither maintains a reusable, structured template with rules for when it applies.

What types of Jira issue templates are there? Four in practice: description templates that pre-fill the description field; full item templates that set fields, labels, components and assignees; hierarchy templates that create a parent with its sub-tasks or an epic with its children in one action; and triggered templates that fire automatically on a transition or field change.

Can I template sub-tasks, not just the parent? Not natively in any reliable way. Cloning copies sub-tasks but also copies everything else, and automation rules can create sub-tasks but need rebuilding for every variation. Hierarchy templating is the main reason teams move to a dedicated app.

How do I create an issue template in Jira without an app? The closest native options are cloning a well-formed item and editing the copy, setting a default description on an issue type in a team-managed project, or building an automation rule that creates items with pre-filled fields. Each works for narrow cases and is covered in detail above.

What is the difference between a Jira template and a project template? A project template (or space template on Cloud) sets up a whole new project with its workflows and screens, and Jira does provide those. An issue template pre-fills an individual work item. Jira provides the first and not the second, which is a common source of confusion when people are told Jira “has templates”.

See also: STM overview · STM use cases · Adding a template in STM · Issue type and Sub-task in the Jira glossary.