nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to Clone a Task and Its Subtasks Daily Using Jira Automation?

Catarina de Souza Ribas

So I have this automation that used to work in 2025 for cloning a task everyday with its subtasks attached to it. For some reason, the automation stopped working when it comes to the subtasks. The automation creates the task based on the template, but when it clones the subtasks, the parent issue becomes the template, and not the cloned ticket. Rovo told me to set the Parent issue as the variable i created but its not working and the automation isn't even cloning the tasks now. Any tips on how to solve this issue?

Captura de tela 2026-09-04 165252.png

Accepted answers

All comments

outreach pro

I’ve run into similar issues with Jira automation when cloning parent issues and their subtasks. One thing I’d check first is the order of the automation actions.

If the parent issue is cloned first, make sure the cloned issue is stored in a variable or referenced from the “created issue” context before attempting to clone the subtasks. The subtask’s Parent field should point to the newly created issue, not the original template issue.

I’d also check whether the automation rule is still able to access the cloned issue’s key/ID after the recent Jira changes. Testing the parent clone action separately first can help identify whether the problem is with the variable or with the subtask cloning step itself.

Trudy P Claspill

Hello @Catarina de Souza Ribas

Welcome to the Atlassian community.

Can you please show us the details of your Create Variable step?

How is the item to be cloned selected? Are you using a JQL in the Scheduled Trigger? If so, can you share that JQL?

Lastly, can you show us your entire rule, please, just so we can see if there might be something odd in the remainder of the rule that could be affecting this?

Jovânio Junior

Hi Catarina - Welcome to the Atlassian Community!

Looking at your rule, I think the main issue is the context change inside the Sub-tasks branch.

When Jira Automation enters a branch for related work items, {{issue}} starts referring to the item in that branch — in your case, each original sub-task — not the parent/template issue anymore. Atlassian documents this behavior explicitly.

Your overall approach is still valid, though. The important part is to capture the newly cloned parent immediately after cloning it, before entering the sub-task branch.

I would structure the rule like this:

Scheduled trigger
Clone the template parent task
Create variable
Name: cloneparent
Value:
{{createdIssue.key}}

Atlassian documents {{createdIssue}} as the previously created work item in the flow, and {{createdIssues}} is also supported by the Clone work item action.

Then:

Branch → Sub-tasks
Inside that branch, clone the current sub-task
Set the cloned sub-task's Parent field to:
{{cloneparent}}

So the structure should effectively be:

Scheduled
↓
Clone parent template
↓
Create variable
cloneparent = {{createdIssue.key}}
↓
Branch: Sub-tasks of template
↓
Clone sub-task
↓
Parent = {{cloneparent}}

This is also very similar to Atlassian's own documented pattern for scheduled creation of a task and its sub-tasks: they save {{createdIssue.key}} into a variable and then use that variable as the Parent for the sub-tasks.

One thing I would change from your screenshot is to make sure the variable stores the key, not the entire work item object:

rather than:

I would also add a Log action immediately after creating the variable:

Cloned parent: {{cloneparent}}

If the audit log returns something like ABC-123, then you know the parent clone is being captured correctly before the sub-task branch starts.

I don't think you need a more complicated solution yet. Your rule structure is very close — the key is preserving the cloned parent's key before Jira changes context to each original sub-task.

Hope this helps!

Michał Krysiuk - Terano Apps

Hi Catarina,

I think the important part here is where you capture the cloned parent.

Once the rule enters the Sub-tasks branch, the issue context changes to each original sub-task. So I would save the newly cloned parent's key before entering that branch.

Something like:

Clone the template parent
Create variable:
cloneParent = {{createdIssue.key}}
Add a Log action temporarily:
Cloned parent: {{cloneParent}}
Branch → Sub-tasks of the original/template issue
Clone the current sub-task
Set the cloned sub-task's Parent to:
{{cloneParent}}

The important bit is storing the key:

{{createdIssue.key}}

rather than relying on {{issue}} later in the branch, because by then the context has changed.

If the log prints something like ABC-123, but the cloned subtasks still end up under the template, I would then check whether the Parent field is actually being overridden in the Clone action.

I recently wrote up essentially the same pattern for creating an Epic → Stories → subtasks hierarchy with Jira Automation, including why {{createdIssue}} needs to be captured before the next context/change:

https://community.atlassian.com/forums/App-Central-articles/How-to-create-a-Jira-Epic-with-all-its-Stories-and-subtasks-in/ba-p/3284320#M17100

The structure is slightly different, but the parent-key handling is the same.

Catarina de Souza Ribas

1- my create variable rule

2- my JQL for the Scheduled

3- my Clone work item for the subtasks

4- my Clone work item for the parent task

Evelin Bayer - codefortynine

Hi @Catarina de Souza Ribas ,

great to see you've already got some helpful input on troubleshooting your Automation!

Cloning a hierarchy with native Jira Automation can get a bit tricky, as you need to handle the parent/subtask relationships yourself.

An easier alternative is a Marketplace app like our Deep Clone for Jira. It handles cloning the subtasks for you and can also be combined with Jira Automation for scheduled cloning.

Full disclosure: I work for codefortynine, the team behind Deep Clone.

Olga Cheban _TitanApps_

@Catarina de Souza Ribas hi!

Building such a flow in automation is possible, but it can get fragile, as you've seen. Jira rules don't always handle automations well when several levels of hierarchy are involved. If the goal is a repeatable task with the same subtasks, using a work item template is often steadier and the most straightforward.

For similar tasks, we use our own solution Smart Templates for Jira. It allows you to save any set of tasks with child work items as one reusable template. Then you can auto-generate the whole structure automatically on a schedule. Smart Templates has its own built-in (and user-friendly) Scheduler, so you don't need to set up any Jira rules for that.

Here's what a schedule for daily auto-generation looks like:

I see you already use variables. Smart Templates support them as well, so you can easily adjust this template to your needs. Small teams can use our solution for free.

I hope this helps!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

task

clone

automation

sub-task

jira-automation