Need help creating a transition automation that is dependent on a custom field.

[Giovanni Sanchez]

Hi all,

I apologize if this has been asked before, but I haven't been able to find anything relevant to what we need. I am trying to create a transition workflow automation that is dependent on the current status of a custom field. Here is what I mean to provide more information.

I have a custom field called Data Impact that is required in 5 of my projects; inside of Data Impact, there are 3 options: No Impact, Will Impact, and May Impact. When a user creates a ticket for one of these 5 projects, and select No Impact, then the ticket will be created normally with no automation. Now, if they select May or Will Impact, then it will trigger an automation that will create a ticket with a copy of the details from the original ticket into our Data Governance project so a team can review the request. That is all fine and dandy and works as intended. 

The issue I have, which I have tried to figure out but keep creating duplications, is on the transition workflow/automation. So I have a similar automation as the one when a ticket is created but it is tied to when the ticket is transitioned from Open to Selected for Development, there is a validator set where it check again if Data Impact was altered from the original status (No Impact, Will/May Impact) I need to create a working automation that looks to see if that status has changed from it's original status to something else (excluding No Impact) If it has, then it should create a ticket in the data governance project. If it didn't change at all then it should do nothing. But I haven't figured out how to do it correctly without creating duplication tickets. I have used issue condition, if/else block as well but not getting right, so any help will be for sure appreciated.

[Bill Sheboy]

Hi @Giovanni Sanchez 

For a scenario like this where an issue is created in another project, a better way to prevent duplications is to explicitly check if that issue exists before the create issue action.  That could be done with a JQL condition or the lookup issues action plus a condition.

As the issues are in different projects, the rule scope will need to be multiple-project (or global).  The reason is project-scope rules can create issues in other projects, but they cannot access them otherwise (i.e., see fields, make updates, etc.)

Your Jira admin will need to help with the scope change as that is done from global rule administration.

Kind regards,
Bill

[Giovanni Sanchez]

Hi @Bill Sheboy it's not that it's creating a duplicate of the issue in another project, it's not that I am not able to create the automation be a "smart" validation that checks the status of a field to do what I need it to do. Instead I have 2 automations that are fighting each other and because of that, they are creating duplications.

[Bill Sheboy]

Ah, thank you for clarifying!  Please try disabling / removing one, and change your rule to use an if / else condition to handle the different cases in one rule: https://support.atlassian.com/cloud-automation/docs/jira-automation-conditions/#If-else-block