Blog · 22 September 2026

Jira subtask template: four ways to get the same subtasks every time

A Jira subtask template is the thing Jira Cloud does not have: a saved list of child steps you can put under a work item again next time without retyping them. Jira has no store of reusable subtasks, so every answer is one of four workarounds — clone an item that already has the right children, write a Jira Automation rule that creates them, buy a template app that saves the whole hierarchy, or use a recurring rule that holds the parent, the children and the schedule in one record. They differ far more in what they carry into each child than in what they cost, and that is the part most comparisons skip.

The short verdict #

• The same subtasks, once in a while, with a person there to press the button? Clone. It is free and native — just remember the children are opt-in and the summary comes back with a prefix.
• You only need child summaries, nothing else? Jira Automation's Create sub-tasks action does exactly that and no more. Read the next section before you plan anything richer.
• You need whole epic → story → subtask trees, per-project defaults, or variables inside descriptions? That is a template app. Issue Templates for Jira and Easy Templates for Jira both build hierarchies, and both are free below eleven users.
• The subtasks are the same because the work repeats — every Monday, every month-end, every quarter? Then a template alone leaves you doing the one thing a machine should do: remembering. Recurring Work Items for Jira stores the children with the schedule.

What each option actually carries into a child #

Option 1: clone an item that already has the right subtasks #

Cloning is the free answer, and it is better than its reputation — but the children are not automatic. Atlassian's Jira Cloud documentation (checked September 2026) says cloning copies "most information from a work item like the Summary and Description fields and more", and then lists what is not automatically cloned but can be included:

Attachments, Subtasks, Links, Custom fields (if they're set up to be cloned), Comments, Child work items (for Epics).

So subtasks come across only if you tick Include in the clone dialog. Two other things to know: the docs state that "the prefix Clone is automatically added to the Summary of a cloned work item", which you then edit out of the parent every time, and that you need the Create work items permission in the space.

Clone is the right answer when a person is always the trigger. It costs nothing, it needs no admin, and the structure is already correct because you are copying a real item that worked.

Option 2: Jira Automation, and the sentence that decides it #

Jira Automation has a dedicated action for this, and its documentation is unusually blunt about the limit. Of the Create sub-tasks action, Atlassian's cloud automation docs say (checked September 2026):

This action only supports setting the Summary of the sub-task.

And immediately after:

Selecting Add fields will convert the Create sub-tasks action into a Create work item (work item type: sub-task) action, allowing you to set additional fields.

Read those two sentences together, because they are the whole design. One Create sub-tasks action can produce five children — as long as all you want is five summaries. The moment one child needs a description, an assignee or a custom field, that action stops being the one you are using: you are writing a Create work item action, and you write one of those per child. A six-step checklist with descriptions is six actions in the rule editor, six places to edit when the checklist changes, and six creates counted against your automation usage. Our Jira Automation pricing breakdown covers what that counting costs once a rule runs across a whole site.

Automation is still the right answer if your subtasks genuinely are bare titles — "Draft", "Review", "Publish" — and you already maintain rules.

Option 3: a template app, when the structure is the point #

Two apps in the Atlassian Marketplace are built for exactly this, and both go further than subtasks alone.

Easy Templates for Jira (AppLiger) says on its own product page (checked September 2026) that you can "Save any issue - or a complete Epic, Story, Task and subtask hierarchy - as a reusable template", and that templates preserve "Child and linked issue relationships". Its FAQ answers the hierarchy question directly: "Save an Epic with its child issues as one reusable template and recreate the complete hierarchy without rebuilding it issue by issue." The page states it is "Free forever for Jira sites with up to 10 users".

Issue Templates for Jira (Deviniti) stores a work item with its children and linked items and applies it manually, through a workflow post function, or by a Recreate action on an existing item — which is what most teams end up using it for.

Cloud list prices from the Atlassian Marketplace, in USD per year, as of September 2026. Renewal is the number worth reading: both vendors publish a first year at roughly double what the following years cost.

Stay with a template app if what repeats is the shape, not the calendar. A bug-report template, a release checklist, an onboarding epic — those are applied when a human starts something, and an app that rebuilds the tree on demand is exactly the right tool. What neither app brings is a clock: the template waits to be applied, and something else has to do the applying.

Option 4: a recurring rule, when the subtasks repeat on a schedule #

If you are searching for a Jira subtask template because the same checklist has to exist every month, the template is only half of what you need. In Recurring Work Items for Jira, the rule is the template — one record holds the parent item and its ordered list of children, and the schedule that creates them.

The children are deliberately thin, and the reason is worth stating because it is a design decision rather than a limitation. Each child says only what makes it a distinct step: its work type, its summary, its description and its own assignee. The labels, priority, reporter and due date come from the parent and are inherited by every child, because those describe the batch of work rather than one step of it. A rule that created seven children would otherwise need seven copies of four fields you were going to set identically anyway.

A few specifics:

• Child summaries and descriptions are token sources, exactly like the parent's, 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.
• A rule creates up to ten subtasks per run. That is a deliberate bound — every child is one more Jira call inside the app's execution budget — and it is refused when you save the rule, not at 3am when the rule fires.
• Rules are scoped to one project, so a schedule you write for one team does not start creating work items across the site.

How to switch, from whichever option you are on #

1. Open the item whose subtasks you keep recreating — the cloned original, or the one your template app rebuilds.
2. In the project, open Recurring Work Items and create a new rule with the same work type, summary and description. Set the labels, priority, reporter and due-date offset on the parent, once.
3. Add one child per step, in order, giving each a summary and — where it matters — a description and an assignee.
4. Set the schedule, and use the preview to confirm the dates land where you expect before you save.
5. Leave the old rule or template in place for one cycle, then delete it once the first scheduled item has appeared with the right children.

If what you have is an Automation rule full of per-child Create work item actions, step 3 is where the saving shows up: the list of children becomes rows in one editor rather than actions in a rule.

Related reading #

• Jira task template: reuse an issue, or have it created for you — the same question one level up, about the parent item.
• Jira checklist template: where the steps should live — when the steps belong inside a description rather than as subtasks.
• Jira recurring tasks: Automation, cloning, or a scheduling app? — the scheduling half, on its own.