Jira templates with sub-tasks: the same children under every epic or work item

Some work always breaks down the same way. Here is how to make a Jira Cloud work item or epic start with the same sub-tasks or stories every time, with Jira alone and with an app.

By Rolf Eriksen Published 21 October 2026 10 min read

Checked against Atlassian’s pages on 21 October 2026 · We make an app for this (disclosure)

Jira Cloud has no template that carries sub-tasks or child work items. It has two ways to get there.

• Clone a template work item. Keep one work item with the sub-tasks, or one epic with the stories, and clone it with those included.
• An Automation rule. When a work item of a given type is created, the rule creates its sub-tasks, or the stories under a new epic.

Both work. Cloning copies a live work item that anyone with edit rights can change. A rule runs after the work item exists, needs an admin to change its list, and uses Automation steps each time it runs. If you want people to pick from several templates, each with its own children, an app such as ours does that.

A note on words: Atlassian’s newer pages say spaces, work items and work types for projects, issues and issue types. This page uses both.

Most teams have a few pieces of work that always break down the same way:

• A release. An epic with stories for the changelog, the release notes, the deploy and the check afterwards.
• Onboarding a new starter. A task with sub-tasks for the laptop, the accounts, the first week’s meetings and the buddy.
• Incident follow-up. A work item with sub-tasks for the timeline, the root cause, the fixes and the write-up.
• A customer go-live, an audit, a quarterly review. The same ten steps every time.

Without a template, someone creates the parent and then types each child by hand. It is slow, and the list drifts. One release has the step for release notes, the next one does not, because the person creating it worked from memory.

What people want is simple to say: create the parent, and have the same children appear under it, in the same order, every time.

Keep one work item, or one epic, that is never worked on. Give it the sub-tasks or child work items you want. When you need a new one, clone it.

The steps

From Atlassian’s Clone a work item page:

1. Open the template work item.
2. Select ••• → Clone.
3. Edit the Summary.
4. Edit the Assignee and Reporter if needed.
5. Under Include, choose what to copy. For this job, that is Subtasks, or Child work items when the template is an epic.
6. Select Clone.

What carries over, and what does not

Atlassian says a clone copies most of a work item’s information, such as its Summary and Description. Some things are copied only if you choose them under Include: attachments, sub-tasks, links, custom fields that are set up to be cloned, comments, and an epic’s child work items. You need the Create work items permission in the space.

The clone is a separate work item, but Jira links it to the original. Its summary starts with the word “Clone”. Atlassian notes that a space admin can use Automation to remove that prefix in bulk. The page also warns that the clone experience it describes may not yet be enabled on every site, so your dialog may look different.

Where it stops

• The copies carry the template’s own text. The new work item starts with the template’s summary and description, and each sub-task or child keeps its own summary. Atlassian’s page describes no way to put the new work item’s name or date into the children. Someone renames them by hand, or lives with “Release checklist: update changelog” on every release.
• The template is a live work item. It turns up in searches, filters and boards, and anyone who can edit it can change the template for everyone.
• Someone has to remember the options. Forget to tick Subtasks or Child work items and you get the parent alone.
• Not stated by Atlassian. The Clone page does not say whether cloning an epic with its children also copies the children’s own sub-tasks, or whether there is a limit on how many children are copied. We have not tested it for this guide, so we do not claim either way.

Jira Automation can add the sub-tasks for you. Atlassian’s trigger reference says the Work item created trigger can be used to customise the new work item, including adding sub-tasks.

The rule

1. Trigger: Work item created.
2. Condition: the work type is the one you want, for example Task. Without it, every new work item gets the sub-tasks.
3. Action: Create sub-tasks, with one summary per sub-task.

Two details from Atlassian’s action reference. Create sub-tasks sets only the Summary of each sub-task. To set other fields, select Add fields, which turns the action into a Create work item action with the sub-task work type. Both actions accept smart values, so a summary can include details of the work item that started the rule.

If more than one kind of work item needs sub-tasks, you need a rule, or a separate condition and action, for each kind. A “new starter” task and an “incident follow-up” task are two patterns, and the rule has to tell them apart by something it can see, such as the work type or a label.

For an epic, the children are stories or tasks, not sub-tasks. The Create work item action creates a work item of any type in a space, with the fields you choose. Atlassian’s knowledge base example creates an epic and then its children, each with its Parent set to the epic. On an epic you create by hand, the same idea gives this rule:

1. Trigger: Work item created.
2. Condition: the work type is Epic.
3. Actions: one Create work item action per story, each with Parent set to the work item that triggered the rule.

For sub-tasks under those new stories, add a branch. Atlassian’s branch reference describes an All created issues branch that acts on the work items made by Create or Clone actions earlier in the rule. Inside it, a Create sub-tasks action adds the same sub-tasks to each of them. Different stories needing different sub-tasks means more conditions or more branches.

Two warnings from Atlassian’s pages. Branches over several work items run in parallel, and a rule cannot rely on one branch’s changes being there for another. And when a rule creates a parent and then children one after another, the smart value {{createdIssue.key}} changes with each new work item. Atlassian’s KB on cloning a story with its sub-tasks stores the parent’s key in a variable first for that reason.

Our guide to a Jira epic template with stories and sub-tasks sets this rule out step by step, with what each run costs and three epics to copy.

• It runs after creation. The person in the Create dialog sees only the parent. The children appear once the rule has run.
• It counts towards your Automation usage. Atlassian’s usage page says every trigger, condition, action, branch and loop that runs counts as one step, against a monthly allowance that depends on your plan. A rule on Work item created runs for every new work item in its scope, including the ones its condition then turns away. Our step billing guide has the arithmetic.
• Changing the list means editing the rule. Atlassian’s permissions page says rules for one space are managed by its admins (Administer spaces and Browse spaces in a company-managed space, Administrator access in a team-managed one), and rules across Jira by people with Administer Jira. A Jira admin can turn off space admins’ access to rules. The person who knows the onboarding checklist is often not one of them.
• Nobody picks. The rule decides from what it can see on the new work item. People cannot choose “the short release checklist” this time.

Both can get the children there. Neither lets a person choose one of several templates at the moment they need it. Cloning cannot put the new parent’s name into the children’s summaries, and a rule can only by writing it into the rule.

We make Issue Templates & Create Defaults for Jira. That is why this page exists. This section describes version 2.7.0.

What a template can hold

A template can include child work items, for example stories and tasks under an epic, and sub-tasks under each child, in a set order. A template for a task or bug can hold its sub-tasks directly: a bug template that always starts with “Reproduce {{parent.key}}”, “Fix and add a test” and “Check the fix where it was reported”. One template holds up to 30 children, up to 20 sub-tasks per child, and up to 100 work items in total.

The summaries and descriptions of the children can use three placeholders: {{parent.key}}, {{parent.summary}} and {{today}}. A child called “Release notes for {{parent.summary}}” then names the release it belongs to.

Starting a new work item from a template

On a project’s Templates page, the person picks a template. Jira’s own Create dialog opens, filled in from the template for the top work item. They check it and create it as usual. After it is created, the app creates the children under it, and the sub-tasks under each child, in the template’s order.

Adding children to a work item that already exists

On an existing work item, ••• → Add work items from template shows a preview of the tree that will be created. After the person confirms, the app adds the children under that work item. The work item itself is not changed. The action only adds: it never edits or deletes anything. Our guide to adding the same sub-tasks to an existing work item covers this case with Jira alone too.

Checks first, and what happens when Jira says no

Before anything is created, the app checks that every work type in the template exists in the project and fits at its level: a standard work type under an epic, a sub-task type under a story, task or bug.

Jira can still refuse one item, for example because a required field the template does not fill is empty. Everything already created is kept. The person can then:

• Resume, after fixing the cause. Nothing is created twice, even if the run was interrupted.
• Skip that item, and whatever goes under it, and create the rest.

Children are created with the person’s own Jira permissions. If a work type’s create screen lacks a field the template sets, such as labels, priority or description, that field is left out for that item and the app says so.

What it does not do

• It does not fill in Jira’s Create dialog by itself. The dialog is filled in only when someone picks a template on the Templates page.
• It does not set default values for fields.
• It adds no custom fields to your Jira.
• It records nothing about who uses it.

• Two levels. Children under the top work item, and sub-tasks under those children; or sub-tasks straight under a task or bug. Nothing deeper.
• Jira Cloud only. Not Data Center or Server.
• Required custom fields. If a work type has a required custom field the template does not fill, Jira refuses that item. You can Skip it or fix the cause and Resume, as above.
• Size. Up to 30 children, 20 sub-tasks per child, and 100 work items in one template.

The full setup and limits are in the documentation. If one checklist under one work type is all you need, and an admin owns it, an Automation rule may be enough.

Can Jira create sub-tasks automatically when a work item is created?

Yes, with an Automation rule: the Work item created trigger, a condition on the work type, and the Create sub-tasks action with one summary per sub-task. The sub-tasks appear after the work item is created, not in the Create dialog, and each run counts towards your Automation usage.

How do I make an epic template with stories in Jira?

Without an app, keep a reference epic with its stories and clone it with Child work items included, or write an Automation rule whose Create work item actions set the Parent field to the new epic. Issue Templates & Create Defaults for Jira 2.7.0 lets a template hold the stories and their sub-tasks, in order.

Does the Issue Templates app fill in Jira’s Create dialog by itself?

No. The Create dialog is filled in only when someone picks a template on a project’s Templates page. The app does not set default values for fields and adds no custom fields.

Does Add work items from template change the work item I run it on?

No. It adds children and sub-tasks under that work item and leaves the work item itself as it is. It never edits or deletes anything.

What does the Issue Templates app cost?

Prices and a free trial are on its Atlassian Marketplace listing. We do not repeat the prices here, so they cannot go out of date on this page.

• Jira issue templates in Jira Cloud: default descriptions, block templates, Automation, cloning and request types, for the fields of a single work item.
• Issue Templates & Create Defaults for Jira: the app’s page.
• Issue Templates documentation: setup, child work items, the checks, limits and data.
• Jira epic template with stories and sub-tasks: the rule for an epic’s stories and their sub-tasks, its step cost, and three epics to copy.
• Jira epic template: free text for an epic’s description and checklist.
• Recurring tickets in Jira Service Management after Automation step billing: what Automation steps cost.
• Jira employee onboarding template with sub-tasks: the same steps for every new starter.

Every statement about Jira on this page comes from the Atlassian pages below, read on 21 October 2026. Where Atlassian’s pages did not say something, we left it out or said so.

• Clone a work item (checked 21 Oct 2026)
• Jira automation triggers (checked 21 Oct 2026)
• Jira automation actions (checked 21 Oct 2026)
• Jira automation branches (checked 21 Oct 2026)
• Automation Rule: Create an Epic along with its child issues (KB) (checked 21 Oct 2026, last changed 17 Sep 2024)
• Automation: How to clone tasks/stories along with their sub-tasks (KB) (checked 21 Oct 2026)
• How is your automation usage calculated (checked 21 Oct 2026)
• Permissions required to manage automation flows (checked 21 Oct 2026)

Changelog

• 21 October 2026. First version, describing Issue Templates & Create Defaults for Jira 2.7.0.

Corrections

None yet. If something here is wrong, email [email protected]. We will fix it and say so here.