How to avoid getting duplicates when field value changes?

[Rita Arellano]

Hello, 

I am able to create stories through automation whenever a component is added for the epic for all the different teams we have. However, my trigger is set to - "when issue is updated," so basically - yes, stories are created, but if anything else is updated on the epic - it will also create a story too. Therefore, giving me duplicate stories - because in a sense the issue is being updated per the trigger rule. 

I have tried changing my trigger to "When value changes for component" but that is giving me duplicates stories every time I add a new component or even delete a component. 

How can I change my trigger from 'when issue is updated' to 'when value changes for component' with out getting duplicates every time the component field is either updated or a value there is deleted? Please see my rule below: 

[Bill Sheboy · Accepted solution]

Hi @Rita Arellano 

Using the Field Value Changed trigger for Component seems like it should work, particularly as you have specific conditions to check for any existing issues with each Component value. 

The other alternative is to use the generic Issue Updated trigger and then add a smart value condition to confirm the changelog value shows the Component field changed: https://confluence.atlassian.com/automation/jira-smart-values-issues-993924860.html#Jirasmartvaluesissues-changelogchangelog

Please post an image showing the audit log details for the rule execution with the Field Value Changed trigger.  That may help explain what you are observing.

Until we see that...

Are the newly created issues added to the Epic by the rule in the action?  Have you confirmed that is working as expected?

Your rule is using the Related Issues Condition to check for existing issues with JQL, correct?

Kind regards,
Bill

[Rita Arellano]

Hi @Bill Sheboy , 

I have the trigger set to when value changes for components and although I have set a condition at a branch level for each component in where if component does not match specified JQL - then proceed and create a story. I am still seeing duplicate stories get created - duplicates as in - same component and summary for each story. 

So, each time I add a component to the component field in the epic - yes story gets created and the story prefixes the epic summary with the component entered in the epic is copied to the story - perfect there. FYI: Each story has a summary that looks like this (Component name - epic summary) Component is prefixing the summary and the component is also set in the story’s field. All that works fine. 

Issue is when I add another component to the epic and there is already an existing component - it will then create a duplicate story of the existing component that is already there (component and summary) and then create the story for the newly entered component. This is what I am seeing: 


 
This is my JQL restriction that I have at a branch level  to avoid getting duplicates. 


Audit Log, stories are to be created on a different project, so epic lives in another project and stories are created in another - works fine there too, but here are the audit log details: 

Rule: 

[Bill Sheboy]

Thanks for that information, @Rita Arellano 

You note Epic and child issues are in different projects.  In your rule details, is this rule for a single-project or multiple-project scope?

A single-project scope rule can only access issues in that project.  Please change the project scope to include all of the relevant projects and then re-test the rule.  Global or multiple-project scope rules are managed from the global admin area, so please work with your Jira Site Admin to make that change.

[Rita Arellano]

Hi @Bill Sheboy 

You are correct. As soon as I kept everything under one single project the rule worked as expected. At the moment I will keep things under one project, will reach out to my Jira global admins if ever we do have a strong need to include this rule to other projects. Appreciate your help on this one too.

[Bill Sheboy]

Awesome; I am glad to learn that helped!

To clarify my earlier comment: project-scope rules can create (or clone) issues in other projects, but they cannot see them otherwise for triggers, branches, conditions, and actions.  Those need global or multiple-project scope rules.