Why is My Automation Not Creating the Other Story?

[Rita Arellano]

Hello all, 

I am able to create the first story from this automation and also have ensured that no duplicates get created. However, when I then try to manually trigger again to create the second story - it just wont create. 

My scenario: 

• When manually triggering a story it creates a story and adds the latest release from the epic that the story is linked to - end result: Story is created with the epics last fix version. 
  
  
• If Story with the existing component exists and the epics last fix version is already present in that story - do not create. 
  
  The above works great when I create the first story, but the automation will not create the second story when manually triggering on the other story that needs to get created - or clicking on any other story for that matter. 
  
  See my automation rule and audit logs. 
  
  
• Both pieces within the branches have the identical fields and values to create the story: 
• 

[Trudy Claspill]

Hello @Rita Arellano 

I'm a little confused about your references to manually triggering the rule to create the first story and then manually triggering it again to create a second story. Are you really triggering the rule twice, or are you triggering it once and expecting 2 issues to be created?

Are the two images for just one rule or for two separate rules?

If it is for one rule, is the second image showing the steps that come after the steps in the first image? And between these two images are you showing us all the steps in the rule?

Based on the image of the log file it seems like the rule images represent one rule with two "For Epic" branches.

If that is the case it appears that the Lookup Issues action in the second branch is finding some issues, and therefore the condition is not passing and the issue creation in that branch is not executing.

Does that not match your expectations?

Can you provide a step by step walk through of what actions you're taking and what actions you expect the automation rule to execute. Include example data for the parent Epic in your scenario, and from the Stories that you expect will or should not be returned by each Lookup Issues action.

[Rita Arellano]

@Trudy Claspill Here is what I’m attending to do:

Epic can have several releases for the fix versions field and so can a story - by design. I have an automation that copies the epic release to the story field - that works great.

The issue is since we have an automation that copies the releases from the epic down to story, we end up with stories that also have many releases. Due to certain reports in our dept we wish to only end up with one release per story.

So my automation to keep several releases at an epic level, while only keeping the latest release at a story level, should work as follows.

Why do stories need to get created? Because there will be a story for each release for each team. 

1. Wish to trigger from the story that is linked to the epic. The epic should have more than one fix versions.

2. We would trigger on an existing story that has the 1st release entered on the epic. 

3. the trigger should check if another story with the same component that triggered the issue exist and same fix versions.

4. If does not exist - create the story. 

pictures are for one automation 

[Dathathreyaswamy Mothupalli]

Hi @Rita Arellano ,

As per the below requirement, It should not create.

If Story with the existing component exists and the epics last fix version is already present in that story - do not create. 

Please verify and confirm.

[Trudy Claspill]

Hello @Rita Arellano 

I'm not sure that I have understood the flow, so tell me if this explanation is correct.

You have an Epic with child stories.

Each child story has a different component.

When a fix version is added to the Epic that information is copied to all child stories by an Automation Rule. That Automation Rule just copies the data to all the child issues. It doesn't check how many Fix Versions values there are.

If there is more than one Fix Versions on the Epic, then you end up with more than one Fix Version on each child story. Instead you want a copy of each child story so each child story has only one Fix version.

Is that an accurate description?

If it is, would the following be an acceptable solution?

When a version is added to the Epic

If the Epic has more that one version

Then clone one set of the child stories that correspond to one Fix version in the Epic

And set the Fix version of these newly created stories to be only the new Fix version added to the Epic

Questions that would influence the solution:

1. Does every Fix Version value on the Epic get the same set of child stories?
2. What fields are you setting in each new story you create in your current automation? Are those values identical to the other stories that have the same Component value?
3. Is a solution that does this without using a manual trigger acceptable?

[Rita Arellano]

I think I have figured this out, I may have overcomplicated this automation. Well the first thing I would like to address is that I needed to branch to the current and not the parent... because I was to manually trigger on each story. Secondly, make some edits on my lookup issues, since now the branching is for current issues. 

I simplified my automation to the below. When user manually triggers on the story - a new story is created capturing the last fix version value from the epic. User must not click on the same story twice for the same fix version - or there will be a duplicate. 

Also, I cant add all the components from our dept to just one automation because there is a limit of how many branches one can create per automation. I would then end up with two manual triggering automations for the same purpose.