Blog · 17 September 2026

Jira task template: reuse an issue, or have it created for you

A Jira task template is a saved version of a work item — its summary, description, fields and often its subtasks — that you apply instead of typing the same thing again. Jira Cloud has no built-in template store for individual work items, so in practice you get one of three things: cloning, which copies an existing item on demand; a template app, which saves the structure properly and applies it when something triggers it; or a recurring rule, which holds the template and the schedule so the item appears on its own. Which one you want depends almost entirely on whether a person is there to press the button.

The short verdict #

• You reuse the same item occasionally, and a person is always there to start it? Clone it. It is free, native, and copies more than most people expect.
• You need an epic with its stories and subtasks, checklists, or variables in the text? A template app is what that is for — Issue Templates for Jira and Easy Templates for Jira both do it, and neither asks you to build the structure by hand.
• The template's whole point is that it repeats — every Monday, the first of the month, every quarter? Then the template is only half the job, and the scheduling half is where these options differ most. Recurring Work Items for Jira carries both in one rule.
• You already write Jira Automation rules and they are not costing you anything? Stay there. Our own Jira Automation pricing breakdown is the honest version of when that stops being true.

What "Jira task template" means — three different things #

The phrase gets used for three unrelated things, and the answers are unrelated too.

This article is about the second and third. If you are after the first, Atlassian's own project templates are one click away when you create a project and no app is involved.

Option 1: Clone the work item #

Cloning is the free answer, and it copies more than its reputation suggests. Atlassian's Jira Cloud documentation (checked September 2026) says a clone copies the summary and description, and that during cloning you can choose to include attachments, subtasks, links, custom fields (if they are set up to be cloned), comments, and child work items for epics. The clone is a separate work item linked to the original, and Jira adds the prefix Clone to the summary, which you then edit out every time.

What cloning cannot do is exist without you. It has no store — the "template" is an old work item somebody has to find, and if that item gets edited, closed into an archive nobody browses, or created in the wrong project, the next clone inherits the mistake. It is the right tool for a handful of re-creations a month and the wrong one for a standard your team is supposed to follow.

Option 2: A template app #

A template app is what you want when the structure matters: an epic with its stories, a task with five subtasks in order, a description with the same eight headings every time.

Issue Templates for Jira (Deviniti) stores templates that recreate a work item "with all its children and linked work items", generates an epic with stories, sub-tasks and linked items, supports variables for dynamic content, and carries checklists and Jira Assets field values — all as described in its own documentation, checked September 2026. It is applied manually when you create an item, by an Apply template post function in a workflow, or by a Recreate action on a work item. As of September 2026 its cloud editions are Standard and Advanced, Advanced adding default templates per item type and availability rules for who can use which template; its pricing page describes monthly subscriptions up to 10 Atlassian product users at a flat rate and larger sites billed per user from the first user.

Easy Templates for Jira (AppLiger) takes the same shape from the other end: its product page (checked September 2026) says you can "Save any issue - or a complete Epic, Story, Task and subtask hierarchy" and that templates preserve "Child and linked issue relationships". It states it is "Free forever for Jira sites with up to 10 users", with larger sites billed through Atlassian according to their Jira user tier.

Both are good at what they are for. The thing to notice is what they say about schedules.

"One of available options to create an issue from a template is to use Automation's Scheduled trigger with Create issue action." — Issue Templates for Jira documentation, checked September 2026

Easy Templates says the same in its own words: apply templates "through Jira Automation or the REST API to create repeatable work on a schedule or from your existing Jira triggers".

That is the honest boundary: the template app holds the content, and Jira Automation holds the clock. For a template you apply on demand that is irrelevant. For a template whose entire purpose is that it repeats, it means you are maintaining two things that have to agree with each other — a rule in one place, a template in another — and the rule is the part that fails quietly.

Option 3: A Jira task template that runs on a schedule #

Jira Automation's Scheduled trigger is the native version of the clock. Atlassian's documentation (checked September 2026) describes it as running "at a fixed rate (for example, every 7 days), or use a Cron expression for more complex schedules" — we wrote up the syntax and its traps in Jira cron expression. The same page notes something worth knowing before you rely on it: "Scheduled flows that reach a Failure status for 10 consecutive executions will disable automatically."

A scheduling app collapses the two halves into one record. In Recurring Work Items for Jira, a rule is the template: it stores the item type, summary, description, due date, assignee, reporter, priority, labels, a parent when the item should be a child of something fixed, your custom fields, and an ordered list of subtasks, where each child inherits the parent's labels, priority, reporter and due date so you only fill in what makes it a distinct step. The text fields are token sources rather than fixed strings, so a monthly rule can produce "Access review — September 2026" and a due date three working days out; the vocabulary is on the tokens page.

There is no cron field. You pick the pattern and the editor shows you the next runs before you save, which is the part a cron expression can never do.

The four options side by side #

Who should stay with a template app #

Genuinely, and this is most readers of this page:

• You apply templates by hand, when someone opens a request or starts a piece of work. A scheduler has nothing to offer you; the clock is the only thing it adds.
• You need whole epics or linked-item trees. Both apps above build those; a recurring rule creates one item with its subtasks, not a multi-level tree.
• You need checklists, Assets field values, or per-group control over who may use which template. Those are template-app features and we do not have them.
• You need templates available across many projects at once. Recurring Work Items is deliberately scoped to the project you turn it on in, so the rules of one team never clatter into another team's board.

When the schedule is the whole point #

Switch when the failure you keep having is a missing item rather than a badly filled-in one: the quarterly access review nobody raised, the monthly invoice reconciliation that slipped two weeks, the weekly backup verification that only exists when someone remembers. Those are schedule failures, and a better template does not fix them.

Two details matter when you get there, because they are what goes wrong with scheduled creation in practice:

• A scheduled rule that fails looks exactly like a rule with nothing to do — the items simply stop appearing. Recurring Work Items keeps a run history per rule with a reason on every outcome, including the skips, and a daily audit counts failing rules so the page tells you rather than waiting for you to ask. Failing rules are never switched off on your behalf.
• Every item it creates carries the label recurring-<rule id>, so you can find everything one rule ever produced with a JQL search — including a rule that ran more often than you meant — without opening the app at all.

How to set one up #

1. Install from the Marketplace and open Project settings → Apps → Recurring work items, then turn it on for that one project. See Install for the two-minute version.
2. New rule, pick the item type, and fill in the template: summary, description, assignee, priority, labels, custom fields, and the subtasks you want under it.
3. Choose the pattern — every week on Monday, the 8th of every month, the last Friday of every third month — and check the next runs preview before saving.
4. If you already have Jira Automation rules doing this, paste the export into Import from Automation and check it first; the check is a dry run that writes nothing.

Free for up to 10 users — not a trial, the whole app — and $5.50 per user per year on the 11–100 user tier above that.

Frequently asked questions #

Does Jira Cloud have built-in task templates? Not for individual work items. Jira has project templates, and it has cloning. A reusable saved item with fields, subtasks and variables comes from a Marketplace app.

Can I use a template and a schedule together? Yes — that is exactly what the template apps above describe, with Jira Automation's scheduled trigger creating the item and the app applying the template to it. It works; it is two moving parts instead of one.

What happens if a scheduled run fails? It depends on the tool. Atlassian's documentation (checked September 2026) says an automation flow that fails ten consecutive times disables itself. A Recurring Work Items rule keeps trying and records each outcome in its history, and the queue retries a run that failed on a Jira outage rather than losing the occurrence — see Troubleshooting for the failure codes.

Is a recurring rule the same as a recurring task? Close enough in practice. If you want the wider comparison — cloning, Automation and the Marketplace scheduling apps against each other — read Jira recurring tasks.