Cloning Conundrum - Rule Creates Duplicate Clones under ALL Epics

[Isabella Musial]

Use Case: 

1. Clone a Capacity and it's Epics
2. 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! ☎️

[Trudy 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. 

[Isabella Musial]

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

[Trudy Claspill]

Hello @Isabella Musial 

I took the below screen image from the image you posted. It appeared in your first message and in your later reply where you asked if I could see it now.

Step 1 is a manual trigger, so not triggered by the creation of a capability.

Step 2 is confirming that the rule was triggered from a specific capability.

Step 3 Clones the capability

Step 4 Is creating a variable. To what is the variable being set?

Step 5 starts a branch to loop over the Epics that are children of the Capability from which the rule was triggered.

Step 6 clones each epic.

I don't see any step to clone the child issues under the Epic.

[Bill Sheboy]

Hi @Isabella Musial 

Yes, and...to the questions from @Trudy Claspill 

Please describe the flow you are expecting for these rules?  For example, are you :

• expecting a person to manually trigger one of these rules, or...
• the first rule does something and you expect the second rule to run as a result of that "something", or...
• ???

As written, those rules run manually when a person triggers them.

Next, and as Trudy described, your rules only handle two levels of issues: the trigger Capability and their child Epics.  There is nothing in the rules to handle the child Stories for each Epic.

How did you plan to handle those?

Kind regards,
Bill

[Isabella Musial]

Rule 1 is not the problem. Rule 2 is. 

[Isabella Musial]

I updated the screenshot above with more details. 

https://community.atlassian.com/forums/Jira-questions/Cloning-Conundrum-Rule-Creates-Duplicate-Clones-under-ALL-Epics/qaa-p/3221121#M1176022

[Bill Sheboy]

@Isabella Musial  -- Regarding the updated text / rule information you provided:

A person runs a rule with a Manual trigger.  The actions of one rule (e.g., cloning an issue) cannot run a different rule with a Manual trigger.  When "chained rules" are needed where one rule's actions trigger another, a different trigger is used, such as Issue Created, and the "Allow Rule Trigger" option is enabled at the top of the rule.

For the rules you show, there are no checks for duplication of created issues.  If a person where to run that rule repeatedly, it would create new issues each time.

Going back to the beginning, what scenario are you trying to solve with these rules?  That is, "why do this?"  Knowing that will help focus the conversation and examination of the rules you are trying.

[Trudy Claspill]

Here is an image of the response you reference in the link you provided

I took my screen image in this reply from that image. Here is the image I pulled, again.

In my reply I enumerated what each step does. 

1. Step 3 clones the Capability itself.
2. Step 6 clones the children of the Capability (the Epics).

None of the 6 visible steps should be creating clones of the child issues of the Epics.

Are there more steps below what has been shown in the images (below step 6)?

In which of these 6 steps does the execution log show that the children of the Epics are being created?

Can you share the rule execution log (revealing all details for every step) for the execution that you say cloned the child issues of the Epics that are children of Capability 1506?

[Isabella Musial]

Sorry to get back to you both so slowly. 

Re Below - This is why I created 2 Rules. Our Jira version does not allow for embedding branching. 

A person runs a rule with a Manual trigger.  The actions of one rule (e.g., cloning an issue) cannot run a different rule with a Manual trigger.  When "chained rules" are needed where one rule's actions trigger another, a different trigger is used, such as Issue Created, and the "Allow Rule Trigger" option is enabled at the top of the rule.

• Step 6 is the last step. 
• Exported. Can I attach .json files? ? 

My coworker did write a C+ script that works. I thought maybe it was the Capability throwing the issue. I am going to test my 1417 Rule on a new Capability now to see if it breaks it or not.

[Isabella Musial]

I tested it again on a new Capability and it worked on each test. I think it was something with 1417 but I cannot see the difference!! 

[Isabella Musial]

I lied. 

I feel like if you have too many stories in the Epic, it starts to duplicate everything.  I have retested about 5 times and still duplicating. 

I see a few of reply's from @Bill Sheboy regarding duplication, but not exactly sure what I should do here. 

• https://community.atlassian.com/forums/Jira-Service-Management/Automation-avoid-duplicates-during-loop-creation/qaa-p/2963295#M201405
• https://community.atlassian.com/forums/Jira-questions/Avoid-duplicate-issue-creation-using-Jira-Automation/qaa-p/2844845#M1060985

So what the script is doing is cloning the first story in the Original Epic, putting it into one epic, recloning the same story and putting it in the second Epic, and so forth. The duplicate story numbers are sequential. 

Here is the audit log. The Keys on the right are the Jira stories that were created. 

I even added a check to see if the story does not have "cloned" label - then clone

Rule 1 that clones the capability and Epics audit log. 

[Isabella Musial]

Should I add some sort of validation? For example: 

If original Epic Summary matches Phase 1, copy stories to the newly cloned Epic that has summary "Phase 1" in it?

This was one suggestion AI did make is to check summaries.

[Bill Sheboy]

Hi, @Isabella Musial 

Earlier in this thread, I asked this question:

Going back to the beginning, what scenario are you trying to solve with these rules?  That is, "why do this?"

Perhaps pausing to get that answer, we can determine what is not working to meet the need...and why.  At this time, I am confused on the scenario.

For example, you could describe it as:

GIVEN some starting condition A
AND some other starting condition B
...
WHEN X happens (e.g., I do X in Jira)
THEN do Y action
AND do Z action

Thanks!

[Trudy Claspill]

Hello @Isabella Musial 

Just to close the loop on our ask for an image showing your second rule, this more recent reply from you is the first one that actually shows the second rule.

All the previous replies show images only of manually triggered rules.

I even viewed the post on an entirely separate computer to ensure I wasn't having some weird browser caching issue.

(That's all I want to say in this reply. More to follow regarding your actual conundrum.)

[Trudy Claspill]

@Isabella Musial 

When you are looking at cloning three levels you do need two rules.

As you have found the first rule can clone the first level and its children (the second level).

The second rule is used to clone the third level.

The trick is that the second rule is triggered by creation of each second level issue. This rule has to find the third level children of the original second level issue and only clone those. 

Let us say we have a Capability/Epic/Story structure like this:

AAA-1
|-- AAA-2
    |-- AAA-4
    |-- AAA-5
|-- AAA-3
    |-- AAA-6
    |-- AAA-7

Your first rule is correctly cloning AAA-1, AAA-2, and AAA-3 to create this structure

AAA-10
|-- AAA-11
|-- AAA-12

You have to add something to AAA-11 and AAA-12 during the Clone Action to help identify that a second cloning action will be need to clone children of the related source Epics AAA-1 and AAA-2 respectively. I am assuming you are using the "NewProgram" label for that.

Your second rule is triggered whenever any new issue is created, but you only want it to proceed for an Epic that has the label "NewProgram". That tells you it was an Epic created by the Clone action in the first rule.

So, let us say this second rule has been triggered for AAA-12.

You need to find out if its source Epic (AAA-1) had any children. This reveals your problem in your second rule.

DSNGINE-2653 is the key for the original Capability that was cloned, right? So this lookup will get all stories under all Epics under that Capability. If we replace that key with AAA-1 in my example data, the returned data set will include AAA-4, AAA-5, AAA-6, AAA-7

Your JQL branch is then looping over all those children and cloning them into the Epic that triggered the rule - AAA-12. That is how you are getting all stories in every Epic.

What you need to do is

1. identify the Epic that was the source and
2. get the child issues for just that Epic rather than for the Capability.

The simplest way to do #1 is record the source Epic key into the newly created Epic during the Clone action in rule #1.

Then in rule #2 get that key and change the lookup action to use that key; i.e.
"Epic Link" = {that key}

Let us know if you understand the suggested modifications, and if those work for you, or if you need more information.

I am 98% positive that the fabulous @Bill Sheboy already has explained this in detail and provided an example of this type of multi-level issue cloning automation in an article or a post somewhere in this forum, but I haven't been able to put my finger on it yet.

[Isabella Musial]

Sorry for not answering some of the questions - I have a bit stressed over this situation. 

We are onboarding teams onto a new process, so we need to set up Jira, Confluence, etc. and because all the new teams are going to follow the same process, we've created templates for things like software development plans, system engineering plans, etcetera in confluence that these teams are going to use as the base of their own SDPS and SEMPs.

Jira will have one Capability per Team, and because the steps to onboard are all the same, +/- a few stories, we want to "templatize" the Capability, the Epics and the Stories in what we are calling the "Transition Plan Backlog".  If this works, then it it's just a one-click process for the user. 

I tried a bulk clone, and it didn't work as needed.  

So:

• When a New Team is ready to be onboarded
• THEN create the Transition Plan Backlog
• AND clone the templatized Capability, Epics, and stories to build out the Jira Board 

Does that help with the context?

[Isabella Musial]

Regarding:

What you need to do is

identify the Epic that was the source and get the child issues for just that Epic rather than for the Capability. The simplest way to do #1 is record the source Epic key into the newly created Epic during the Clone action in rule #1.

Then in rule #2 get that key and change the lookup action to use that key; i.e. "Epic Link" = {that key}

How do I pull the original key for the Source? AI did tell me to look at source, but I did not understand what it was saying. We cannot create new fields, but I can repurpose a field - we have a lot we don't use!!!

- Is this the syntax to use: {{source.epic.key}}
- Can I put this in a repurposed text field?
- Should this be in "More Fields"? 

I tried to just use the JQL Condition in Rule 2 yesterday and it did not work. 

"Epic Link" = DSNGINE-1418 AND summary ~ "Phase 1" AND created >= -5m

Probably missing something. 

I wish there was a "When Issues was Cloned" trigger. 

Thank you both for your help and sorry for my block!! I really appreciate you both! 

[Bill Sheboy]

Multiple level, issue cloning is tricky for out-of-the-box Jira features.  This is why there are so many marketplace apps to help with this need.  (Although, you are using Data Center version, and thus only have a few years left before that sunsets in March 2029, and I recall one can only purchase new marketplace licenses for DC until 2028.)

Before building any additional rules, I recommend discussing this need with your Jira site admin to learn if you either have a marketplace app to help, or could purchase one.  If not...

Using automation rules as a workaround can work, and as Trudy described quite well, your second rule to clone the Stories needs both the source Epic key and the destination:

• The destination is the trigger issue with the Issue Created trigger (with a condition check on the issue type, and perhaps also a check on the grandparent type is a Capability)
• The source might be found in several ways, all of which need to be tested to determine which will help
  • A custom field with the key, although you note not being able to add more fields
  • Checking if the issue links store that the issue "clones" the source; I seem to recall this can be disabled, and thus may not be present
  • A more fuzzy workaround, which may not be reliable, is to add the key as formatted text to an existing field, and then extract that key for use to find the source Epic's child Stories.  The key (no pun intended) is that data must be set when the issue is created, not after.

So, before building / changing this second rule to copy Stories, first confirm how that source Epic key will be found...testing to confirm.  Then you can experiment with small test cases before using this rule further.

[Trudy Claspill]

Adding to what @Bill Sheboy said...

The option to check the links of the newly created issue to find the "clones" link and then get the source issue from that can itself be tricky. So I advocate for the other options - a custom field specifically for the key or formatted text in an existing custom field ensuring no other text is added to that field.

I also agree with Bill's suggestion to talk with your Jira Site Admins about options. In addition to the current proposed solution of cloning issues and the possibility of obtaining a plugin to help, there is the CSV Import option.

If the template Capability/Epics/Stories rarely changes then you might want to instead consider a CSV file that can be imported to create the issues you are currently creating by cloning. The CSV file can include the data for the new issues, and you can have an Import Configuration file so that the users don't have to figure out how to map fields.

Having said that, if you persist with the Automation Rule option:

In rule #1 in your Clone action where you clone the Epic you would set some field during that action to the key of the source epic. Within that action the correct reference for the source epic key would be {{issue.key}}

In rule #2

In step 1 you would change the JQL to

"Epic Link" = {{triggerIssue.field.value}}

where field is the name of the field in which you recorded the source Epic's key. You don't need the "and issuetype=Story" portion unless the Epics may have child issues that are not Stories.

In step 2 you don't need "and key != {{triggerIssue.key}}"

I'm not clear on your purpose for the condition after step 2. That would be checking that the source Story doesn't include the Label value "cloned", but I don't know when or why you are applying that condition to the source Story.

In step 3 I think you have already included this, but in case you have not you would want to set the Epic Link field to {{triggerIssue.key}}

I tried to just use the JQL Condition in Rule 2 yesterday and it did not work. 

"Epic Link" = DSNGINE-1418 AND summary ~ "Phase 1" AND created >= -5m

I'm not clear on what exactly you did or where in rule 2 you did this, so I can't speak to why it did not work.

[Isabella Musial]

Thanks, All. 


@Trudy Claspill 

That was supposed to check if the "cloned" label exists. The rule adds the label to all the issues that are "cloned" from the original

I was thinking maybe I could create 5 JQL Branches where each branch checks each Epic.  This was with AI assistance! So it was checking if the Epic link is 1418 and if the Epic was created within the last 5 min. I don't need the Summary if I am specifying the key. I forgot to pull that out. 

"Epic Link" = DSNGINE-1418 AND summary ~ "Phase 1" AND created >= -5m

[Isabella Musial]

@Bill Sheboy Can you recommend some marketplace apps?

[Bill Sheboy]

@Isabella Musial -- I am not currently using Jira Data Center, and so cannot recommend any specific apps.  With your admin's assistance you could search the marketplace and perhaps try some during a trial period to learn which help.

[Trudy Claspill]

@Isabella Musial 

With the changes I suggested are you still experiencing issues?

Is there a reason to retain hard coded issue keys in your rules, or were you doing that just for testing?

[Isabella Musial]

I have emailed them.....