Use Case: * Clone a Capacity and it's Epics * Clone the stories from the Original Epics into newly cloned Epics Rule 1: Clone Program Backlog ✅ Works like a charm! Rule 2: Clone Program Stories 🔥🔥🔥 My second Rule works Sometimes. I test it on 1506 which has: * Epic 1 has 3 stories * Epic 2 has 2 stories * Total stories: 5 Great! Right!? So I go in and update "1506" to "1417" which is the actual Capability to be cloned. 1417 has (I took 3 Epics out for now) * Epic 1 has 6 stories * Epic 2 has 5 stories * Total stories: 11 The Automation Rule duplicates ALL 11 stories and adds 11 stories into each new cloned Epic. Seriously - that is the ONLY change I made - so why does it do this on 1417 but not 1506?? See side-by-side comparison. AND AI only keeps giving me more options that fail..... 😡 @Bill Sheboy you always have a fix - can you help? I have been trying to figure this out for DAYS, like WEEKS..... MANY DAYS.. I can't any more. Must. Phone. A. Friend! ☎️

Yes, and... One of the Advanced Compare Conditions in the rule you show uses a test on {{triggerIssue.size}} greater than 0. That should be {{lookupIssues.size}} greater than 0.

In rule #1 you needed to record the key of the source epic in a field in the new epic that was getting created by the Clone action. Did you do that? Show us the details of the Clone action from rule #1 specifically show the field where you recorded the source Epic's key. What ever field you put that value into, that is the field that has to be referenced in the JQL in rule #2. I plugged in the placehoder field in my example. You need to replace that with the actual field where you recorded the source Epic's key. "Epic Link" = {{triggerIssue.field.value}} This: ...indicates that the smart value you provided {{triggerIssue.field.value}} could not be resolved to find an actual field with an actual value, so the JQL had no value to which "Epic Link" could be compared.

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

Cloning Conundrum - Rule Creates Duplicate Clones under ALL Epics

Isabella Musial

Use Case:

Clone a Capacity and it's Epics
Clone the stories from the Original Epics into newly cloned Epics

Rule 1: Clone Program Backlog ✅

Works like a charm!

Screenshot 2026-04-13 172457.png

Rule 2: Clone Program Stories 🔥🔥🔥

My second Rule works Sometimes. I test it on 1506 which has:

Epic 1 has 3 stories
Epic 2 has 2 stories
Total stories: 5

Great! Right!? So I go in and update "1506" to "1417" which is the actual Capability to be cloned. 1417 has (I took 3 Epics out for now)

Epic 1 has 6 stories
Epic 2 has 5 stories
Total stories: 11

The Automation Rule duplicates ALL 11 stories and adds 11 stories into each new cloned Epic.

Seriously - that is the ONLY change I made - so why does it do this on 1417 but not 1506?? See side-by-side comparison. AND AI only keeps giving me more options that fail..... 😡

Screenshot 2026-04-13 191948.png

@Bill Sheboy you always have a fix - can you help?

I have been trying to figure this out for DAYS, like WEEKS..... MANY DAYS.. I can't any more.

Must. Phone. A. Friend! ☎️

Accepted answers

All comments

Trudy P Claspill

Hello @Isabella Musial

Let me see if I understand your scenario.

You are trying to Clone three hierarchical layers of issues:
Capability > child Epics > child Stories

Am I correct so far?

Are you trying to do this all with one rule or two separate rules?

The images you shared all appear to be executing the Clone of the Capability, and then cloning the child Epics.

I don't actually see an image that correlates to steps to clone the child Stories of the original Epics into the new Epics.

Are there more steps in the rule than are visible in the image? Where are the steps for cloning the child Stories of the original Epics into the new Epics?

Isabella Musial

Yes.

We do not have the right Branching type to have everything in 1 rule since we cannot nest branching so I had to create Rule 1 and Rule 2 - Rule 2 is triggered to kickoff when Rule 1 has created the new Capability and Epic clones.

Yes, Rule 2 is in the second screenshot.

Can you see the screenshot now?

Isabella Musial

RULE 2 - SIDE-BY-SIDE COMPARISON

Rule 2 is triggered by Rule 1
Rule 2 is created when a new issue (from Rule 1) is cloned and matches the JQL (issuetype = Epic AND labels = NewProgram)
On the left - is rule for cloning Original Capability & Epics based on the Capability key (1417) - this rule duplicates all stories into all the cloned epics from Rule 1
On the right - is the same rule, but it is looking at Capability key 1506. Works perfectly, no duplicates.

Screenshot 2026-04-13 191948.png

Isabella Musial

Seriously, the only thing that changed was the Jira Key. Same Project, Same Initiative, same everything else.

Olga Cheban _TitanApps_

hi @Isabella Musial !

It's true that setting up multi-level cloning with Jira automation rules can get really complex. When you need to handle parent-child relationships across three hierarchy levels, it requires several chained rules - and as you've seen, the result is not always reliable.

Since your goal is essentially to templatize a repeatable onboarding process (Capability > Epics > Stories), there's a simpler way to approach this. I can recommend our solution, Smart Templates for Jira, which lets you save your Capability with all its Epics and Stories as a reusable template - and then recreate the entire set of work items in one go. There’s literally just one button for this, “Create issues from template”. No cloning rules, no duplicate issues, and no need to chain rules together. Smart Templates can be used across projects, so it’s a lightweight and straightforward solution for organizing the onboarding workflow for multiple teams.

Here's what makes it a good fit for your case:

Pre-fill fields like assignees, labels, priorities, and components so each new set of work items is ready to go
Use variables for dynamic values that change per team (e.g., team name, start dates)
Smart Variables like {{now}} can auto-calculate due dates relative to the creation date
If you need to kick off the process automatically, the tool supports automation via the built-in Scheduler. You can also use Smart Templates with Automation for Jira.

Smart Templates are available for Data Center with a free trial, so you can test it with your actual setup before committing.

Here’s an example of a recruitment template for Jira. In this case, it consists of a task + subtasks + checklists, but it can be any work hierarchy.

3.-Jira-Template-for-Recruitment-epic-Smart-Templates-2048x1867.png

I hope this helps! Let me know if you have any questions

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-data-center

data-center