Eriksen Labs

Add the same sub-tasks to an existing Jira work item

The work item is already there: a customer raised it, someone made it inline on a board, or it came in with an import. Now it needs the usual sub-tasks. Here is how to add the same set every time in Jira Cloud, with Jira alone and with an app.

By Rolf Eriksen Published 9 min read

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

Short answer

  • Two or three sub-tasks, now and then: create them by hand from the work item. Jira needs nothing else.
  • The same list, often: an admin builds an Automation rule with the Manual trigger and a Create sub-tasks action. People run it from the work item’s Actions menu. Each run counts towards your Automation usage.
  • Many work items at once: a rule on the Scheduled trigger with a JQL query acts on every work item the query returns.

Cloning does not help: it makes a new work item. For several sets to choose from, with a preview, an app such as ours does that. For sub-tasks at creation, see Jira templates with sub-tasks.

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.

Native option 1: add them by hand

From Atlassian’s Create a work item and a subtask page:

  1. Open the work item you want as the parent.
  2. Under its summary, select Add or create related work. In a company-managed space, choose Create subtask; in a team-managed space, Add a child work item.
  3. Add a summary, then select Create.

In a company-managed space, the page says, sub-tasks must first be enabled by an administrator and the sub-task work type added to the space’s work type scheme. By hand is fine for a few. For a long list that must be the same every time, people work from memory and steps go missing.

Native option 2: a rule you run from the work item

Atlassian’s trigger reference says a rule with the Manual trigger from work item runs when a person starts it, and that anyone with access can run it from a work item’s Actions menu.

The rule

  1. Trigger: Manual trigger from work item. Optionally choose the groups that can run it.
  2. Condition (optional): the work type the list is for, so nobody adds release sub-tasks to a bug.
  3. Action: Create sub-tasks, with one summary per sub-task.

The branch reference says a rule’s main branch always applies to the trigger work item, so the sub-tasks go under the work item the rule was run from. The action reference says Create sub-tasks sets only the Summary; Add fields turns it into a Create work item action with the sub-task type, for other fields. For stories under an existing epic, use Create work item actions with the parent set to the trigger work item, as in Atlassian’s knowledge base example.

To run it, Atlassian’s manual trigger page says: open the work item, open Actions and select the rule. It starts straight away. The trigger can also ask for input first; a person who cancels that form does not cause an execution.

What it costs, and who can change it

  • Usage. Atlassian’s usage page counts every trigger, condition, action, branch and loop that runs as a step, against an allowance that depends on your plan, with no exception for manual triggers. Our step billing guide has the arithmetic.
  • Editing the list. The permissions page gives space rules to space admins and rules across Jira to people with Administer Jira.
  • One list per rule, or one rule with conditions that tell the lists apart.
  • No preview. Atlassian’s pages describe no preview and no check for sub-tasks already there. Run it twice and you get the list twice.

Native option 3: many work items, on a schedule

For a backlog that all needs the same sub-tasks, the trigger reference describes the Scheduled trigger: if you enter a JQL query, the rule’s actions run on the work items it returns.

A schedule repeats, so the query has to stop matching a work item once it has its sub-tasks. Our suggestion, not Atlassian’s: have the rule add a label such as checklist-added, and exclude it in the query. Atlassian says a scheduled rule that fails ten runs in a row is turned off. Every work item it acts on uses steps.

Why cloning does not help here

Atlassian’s Clone a work item page describes cloning as making a duplicate. Sub-tasks or an epic’s child work items can come along, but with a new work item, linked to the original. The page describes no way to copy them onto a work item you already have.

Sub-task sets to copy

For a rule’s Create sub-tasks action or a template. {{parent.key}} and {{parent.summary}} are our app’s placeholders; in a rule, use smart values or leave them out. Keep a set short enough that people do every step.

Release checklist

1. Update the changelog for {{parent.summary}}
2. Write the release notes
3. Tag the release
4. Deploy to production
5. Check the release in production
6. Tell support what changed

New starter

1. Order the laptop
2. Create accounts and access
3. Book the first week’s meetings
4. Name a buddy
5. Check in after the first week

Bug fix

1. Reproduce {{parent.key}}
2. Fix and add a test
3. Review the fix
4. Check the fix where it was reported
5. Write the release note

Content publishing

1. Draft
2. Edit and check facts
3. Images and alt text
4. Final read by a second person
5. Publish and check the live page

Add work items from template: what our app does

We make Issue Templates & Create Defaults for Jira. That is why this page exists. This section follows its documentation as it stands on 21 October 2026.

Since version 2.7.0, a work item’s ••• menu has Add work items from template. It lists the project’s templates that have child work items. Pick one to see a preview of what will be created, in order, with {{parent.key}}, {{parent.summary}} and {{today}} filled in, and any work type that does not fit. Create adds them under the work item. The work item itself is not changed, and nothing already under it is touched.

The tree goes at most two levels down: under an epic, stories and tasks with sub-tasks under each; under a task, bug or story, sub-tasks. Each item can carry a summary, description with a checklist, labels and priority. Since 2.9.0, children can also set the assignee (Jira’s default, unassigned, or the person using the template), a due date a number of days ahead, and components (docs).

When Jira says no

Jira can still refuse an item, for example when a required field is empty. The run stops there and shows Jira’s message. Everything already created is kept, and you can:

  • Resume, after fixing the cause. Nothing is created twice. A run that stopped part-way is listed on the work item as Unfinished, with Resume.
  • Skip this item, leaving out that item and the sub-tasks under it, and create the rest.

Items are created with the Jira permissions of the person using the template.

Where the app stops

  • Someone has to run it. Nothing is added when a work item arrives by import, email or inline create; use an Automation rule for that.
  • No versions or named assignee. Custom fields (text, number, date, dropdowns and more) can be set; user-picker fields cannot.
  • Required fields. One the template does not fill makes Jira refuse that item.
  • Size. Up to 30 children, 20 sub-tasks under each, 100 work items in all.
  • Jira Cloud only. We have not tested service projects or Jira Product Discovery.

It does not fill in Jira’s Create dialog by itself or give fields starting values. If one fixed list is all you need, a manual rule may be enough.

Marketplace Documentation

Which one to use

The options on this page, from the Atlassian pages and our documentation linked above, checked 21 October 2026.

ApproachWho can run itRuns on existing work items?Order kept?Limits
By handAnyone who can create work items in the spaceYes, one at a timeAs typedThe list lives in someone’s head
Manual trigger ruleAnyone with access, or chosen groups; admins edit itYes, the one it is run fromNot stated by AtlassianOne list per rule or condition; no preview; uses steps
Scheduled rule with JQLNo one needs to; it runs on its scheduleYes, those the query returnsNot stated by AtlassianQuery must exclude work items already done; uses steps
CloneAnyone with Create work itemsNo, it makes a new work item–Not for this job
Our appThe person using it, with their own permissionsYes, after a previewYesTwo levels; no user-picker fields; Jira Cloud only

Our plain advice: for a few sub-tasks, type them. For one list an admin owns, a manual rule. For a backlog, a scheduled rule with a careful query. Consider an app when people choose between several sets, want a preview, or need to finish a run that stopped.

Questions

How do I add the same sub-tasks to a Jira work item that already exists?

In Jira alone, either create them one by one from the work item, or have an admin build an Automation rule with the Manual trigger and a Create sub-tasks action, which people then run from the work item’s Actions menu. An app such as Issue Templates & Create Defaults for Jira adds a whole set from a template after a preview.

Does running a manual Automation rule count towards my Automation usage?

Atlassian’s usage page says every trigger, condition, action, branch and loop that runs counts as a step, and it does not make an exception for manual triggers. Its trigger reference says that a person who cancels the input form does not cause an execution.

Can I clone sub-tasks onto a work item that already exists?

No. Atlassian’s Clone page describes cloning as making a duplicate: a new work item, linked to the original, with its sub-tasks or child work items if you include them. It describes no way to copy them onto a work item you already have.

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

No. It adds child work items and sub-tasks under that work item. The work item itself is not changed, and nothing already under it is touched.

What happens if Jira refuses one of the sub-tasks?

With the app, the run stops at that item and shows Jira’s message. Everything already created is kept. You can fix the cause and Resume, which creates nothing twice, or Skip that item and create the rest. A run that stopped part-way is listed as Unfinished on the work item.

Guides in this series

Also useful:

Sources and changes

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.

Changelog

  • . First version, describing Issue Templates & Create Defaults for Jira as its documentation stands that day (child work items since 2.7.0; assignee, due date and components since 2.9.0).

Corrections

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