Jira ticket template

A Jira ticket template is a reusable preset of fields and structure that you apply to a new issue so every ticket starts complete and consistent. A good one carries a clear summary, a structured description (problem, context, expected outcome), a priority, acceptance criteria, and any sub-tasks the work always needs. To create one, build the ticket the way it should look every time, save it as a template, then apply it from the Create screen so the fields fill in automatically. You can copy the structure on this page into Jira by hand, or import it in seconds with an app.

What a Jira ticket template is, and why teams use one

A ticket in Jira is just an issue: a unit of work with a summary, a description, and a set of fields. The problem is that Jira creates every issue from a blank slate. The fields are empty, the description is a flashing cursor, and the person raising the ticket decides on the spot what to write. The result is the thing every team recognises: tickets with a one-word summary, no acceptance criteria, no priority, and a description that says “see Slack.”

A ticket template fixes that at the source. Instead of relying on memory and goodwill, you define once what a complete ticket looks like, and that structure is applied every time a new ticket is created. The summary follows a convention, the description has the right headings, the priority and components are pre-set, and the sub-tasks that the work always involves are already there. The person creating the ticket fills in the specifics, not the scaffolding.

This page gives you a ready ticket structure you can use immediately, the field-by-field reasoning behind it, and the fastest way to make it reusable so you never rebuild it by hand again.

What a good Jira ticket includes

A ticket is only as useful as the information it carries into the workflow. These are the fields that turn a vague request into something a team can actually pick up and act on. For each one, here is what it is for and what separates a good entry from a bad one.

Field	What it is for	Good vs bad
Summary	A one-line, scannable title that says what and where	Good: “Checkout fails on Safari when promo code applied”. Bad: “Bug”
Description	The full context: the problem, the situation, the expected outcome	Good: structured headings with a goal and scope. Bad: “doesn’t work, fix it”
Priority	How urgent the work is, set against a shared scale	Good: “High, blocks release”. Bad: left at the default for everything
Labels / Components	Where the work sits, so it routes and reports correctly	Good: checkout, payments. Bad: no labels, invisible in filters
Assignee	Who owns the next action	Good: a named owner or a clear triage queue. Bad: unassigned indefinitely
Acceptance criteria	The conditions that mean the work is done	Good: a checklist of testable statements. Bad: “when it works”
Linked issues	The bugs, stories or epics this ticket relates to	Good: linked to its epic and blocking issues. Bad: orphaned, no context
Sub-tasks	The standard breakdown the work always needs	Good: the same fixed steps pre-created. Bad: rebuilt from memory each time

Most teams do not need every field on every ticket. They need the right subset, applied consistently. That consistency is exactly what a template gives you, and it is why a template beats a wiki page that tells people what a good ticket should contain. Guidance gets ignored; a pre-filled structure does the work for them.

A ticket template by work type

“Ticket” is the everyday word, but in Jira a ticket is always a specific type of issue, and the best structure depends on the type. Rather than force one shape onto everything, route the ticket to the right purpose-built template.

A bug is a ticket. The fields that matter are steps to reproduce, expected versus actual behaviour, environment, and severity. See the bug template for the full QA-specific structure.

A story is a ticket. Here the structure is the user-story statement, acceptance criteria, and a definition of done. The story template covers it.

A task is a ticket. A task is the general unit of work that is neither a bug nor a user-facing feature, and it usually needs a clear objective and a short sub-task breakdown. Use the task template.

A larger initiative is an epic, which is a parent ticket that groups the stories and tasks beneath it. The epic template shows how to template the whole tree at once.

Think of this page as the umbrella. It defines what a complete ticket looks like in general; the type pages go deep on the fields that are specific to bugs, stories, tasks and epics.

Copy-paste Jira ticket template

Here is a generic ticket structure you can paste straight into a Jira description field. It works as-is for a standard task and gives you a starting point you can trim per type.

h2. Summary
<<what needs to happen and where, in one line>>

h2. Description
*Problem / request:* <<what is happening or what is needed>>
*Context:* <<why this matters, who it affects, any background>>
*Expected outcome:* <<what "done" looks like from the requester's side>>

h2. Details
*Priority:* <<Highest / High / Medium / Low>>
*Component / area:* <<e.g. checkout, billing, onboarding>>
*Links:* <<related epic, blocking issues, reference docs>>

h2. Acceptance criteria
* [ ] <<testable condition 1>>
* [ ] <<testable condition 2>>
* [ ] <<testable condition 3>>

h2. Sub-tasks
* <<standard step 1>>
* <<standard step 2>>
* <<standard step 3>>

A filled example, so the pattern is concrete:

h2. Summary
Add server-side validation to the promo-code field at checkout

h2. Description
*Problem / request:* Invalid promo codes are accepted client-side and fail silently at payment.
*Context:* Affects all web checkout users; raised by support after three refund requests this week.
*Expected outcome:* Invalid codes are rejected before payment with a clear inline error.

h2. Details
*Priority:* High, customer-facing
*Component / area:* checkout, payments
*Links:* relates to EPIC-204 Checkout hardening

h2. Acceptance criteria
* [ ] Invalid codes are rejected server-side
* [ ] The user sees an inline error within 200ms
* [ ] A rejected attempt is logged for support

h2. Sub-tasks
* Add server-side validation rule
* Add inline error state to the field
* Add logging and a support runbook note

Copy-paste is fine for a one-off. The moment you find yourself pasting this for the third time, it is time to make it reusable.

Create it once, reuse it

Pasting a block of text still leaves the real work manual: you retype the specifics, you recreate the sub-tasks one by one, and nothing stops a teammate from skipping the structure entirely. Making the ticket a true template removes all of that.

With Process Templates for Jira, you save the ticket once, with its description structure and its sub-tasks, and apply it from the native Create screen. Three things then happen automatically. The description field is pre-filled with your structure, so nobody starts from blank. The sub-tasks are pre-wired, so the standard breakdown appears with the ticket instead of being rebuilt from memory. And variables (the parts that genuinely change, like a date, the current user, or a project reference) fill themselves in on creation, so a value entered once flows into the ticket without retyping.

For teams that create the same structured ticket repeatedly, there is a dashboard gadget that spins up the whole ticket, sub-tasks included, in a single click. It is free for up to 10 users, needs no Jira admin rights, and requires no scripting, so the person who owns the process can set it up themselves.

How to create a reusable Jira ticket template

Copy-paste works once. To make the structure stick, turn it into a real template:

1. Install Process Templates for Jira from the Atlassian Marketplace. It is free for up to 10 users and needs no admin rights.
2. Build the ticket the way it should always look, with the summary convention, description structure and standard sub-tasks from this page, then save it as a template from the issue menu.
3. Turn the parts that change into variables, like priority, component or a date, so the person creating the ticket fills only the blanks.
4. Create new tickets from the template on a prefilled Create screen, or launch the whole ticket with its sub-tasks in one click from the dashboard gadget.

For the full walkthrough, follow the guide to how to create a Jira ticket template. To browse ready-made structures by type, start from the template library.

Frequently asked questions

Does Jira have built-in ticket templates? Not for reusable issue or ticket templates. Jira ships with project templates and lets automation create issues, but there is no native way to save a ticket with its fields and sub-tasks and reapply it on the Create screen. That gap is why issue-template apps exist.

How do I create a reusable ticket template in Jira? Build the ticket the way it should look every time, including its description structure and standard sub-tasks, then save it as a template with an app and apply it from the Create screen. After that, creating a ticket applies the whole structure automatically. Step-by-step instructions are in the how-to guide.

What fields should a Jira ticket have? At a minimum: a clear summary, a structured description (problem, context, expected outcome), a priority, an owner, and acceptance criteria. Tickets that involve a repeatable breakdown should also carry their standard sub-tasks. See the field table above for what makes each one good.

What is the difference between a ticket, an issue, and a work item? They refer to the same thing. “Ticket” is the everyday word, “issue” is Jira’s classic term, and “work item” is Atlassian’s newer name for it. A bug, a story, a task and an epic are all types of ticket.

Related templates

The ticket template is the generic shape; reach for a typed version when the work has one: the bug template for defects, the story template for user-facing requirements, the task template for standalone work, and the epic template for a body of work with children. For tickets that carry a list of sub-tasks, pair it with the checklist template, and verify the acceptance criteria with the test case template. Or browse the full template library for ready-made formats across software, ITSM, HR and planning work.