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; } } }

Jira Automation: Auto assigning the same Parent as the source work item to cloned work items

Stephen Anderson_0fjuvx

Hi Jira Community,

I've been struggling to establish an automated rule that, by default, sets the parent of a cloned ticket to the same parent as the source ticket being cloned.

Here's where I've got to so far but any help/guidance would be appreciated.

Cheers!

Cloned Parent Rule Screenshot.png

Accepted answers

All comments

Marc -Devoteam-

Hi @Stephen Anderson

Welcome to the community.

When will a cloned ticket be created, is this on a specific action in the source issue?

As based on the default Clone action if the original issue has a parent the cloned item will be linked to that parent.

So how do you clone an issue?

Bill Sheboy

Hi @Stephen Anderson -- Welcome to the Atlassian Community!

First thing: what problem are you solving by cloning? That is, "why do this?" Knowing that may help the community offer better suggestions.

Next, what is not working as you expected? What does the audit log show when the rule runs?

Finally, for the rule you show...

In the clone action, are you setting the parent to the "Current Work Item", which is the one the rule branches to?
Please note the Work Item Created action has known racetrack timing problems. Thus, the rule can start before all of the data is available for use...potentially leading to errors and unexpected rule behavior. The mitigation for that is to always add a Re-fetch Work Item Data action immediately after the Work Item Created trigger.

Kind regards,
Bill

Stephen Anderson_0fjuvx

Hi @Marc -Devoteam- , thanks for the warm welcome and Happy Friday!

We primarily clone tickets manually when creating similar requests (to piggyback existing details) or handling spillover during Sprint Planning.

It's interesting to hear you say the default Clone action should link back to the original issues parent. This isn't happening in our current set-up - anytime a ticket is cloned, by default, the parent of the new ticket is set as blank.

Thanks again for your help.

Stephen Anderson_0fjuvx

Hi @Bill Sheboy, thanks for the warm welcome and Happy Friday!

We want to reduce the amount of manual tweaking to tickets required when cloning, especially in Sprint planning, when cloning tickets that are spilling over. It's not a major time saving, but would make life easier.

In terms of what isn't working as expected, anytime a ticket is cloned - the parent mapping of the original ticket isn't replicated in the cloned ticket. The audit log shows it's running successfully which suggests I haven't got the logic correct.

Thanks for the guidance on re-fetch, I've added this in.

Here's a view of the end action - it appears to be set to the work item but it's not unlikely I've got this wrong!

Cloned Parent Rule Screenshot 3.png

Thanks again for your help.

Bill Sheboy

Thanks for that information, @Stephen Anderson

Do you want to Clone the work item or edit a different one, as you now appear to be showing a different rule with different branching?

If you are branching to the Parent, select that field in the Clone action and then select "Work Item" for the value as it will refer to the branched-to item.

FYI -- When using the dropdown field selection in a Clone or Edit Work Item action, the same field cannot also be used in the "Additional fields". Please clear out that content.

Luka Hummel - codefortynine

Hi @Stephen Anderson

While you can achieve this with a Jira Automation, if this is a recurring process for sprint spillover or reusing similar requests, consider our app Deep Clone for Jira instead of maintaining a brittle automation rule. It is designed specifically for cloning work items, including more advanced scenarios and recurring clone setups.

With Deep Clone you can clone much more reliably than with a hand-built rule, and for larger hierarchies there is also Epic/Tree Clone, which is built to keep the hierarchical structure.

Clara Belin-Brosseau_Elevatic

Hi @Stephen Anderson

I don't know if you managed to solve your use case with Automation but it's true that it can be sometimes rather complex to set up and afterwards, to maintain.

Our app Elements Copy & Sync was actually built to deal with this kind of use case: you can easily set up a configuration that clone a ticket, link it to its source issue and also share the same parent issue.

To do so, you have to create what we call a "Copy & Synchronize Jira work items" recipe and define from which space you're cloning, to which space and which fields should be cloned.

Make sure you add the parent field in the field mapping section:

Capture d’écran 2026-03-16 à 20.04.46.png

You can try the app for free to see if it can help with your specific use case.

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