Automation on Work Item Created and status

[Fredrik Jonsén]

Hi. I have the following automation.

As you can see, this is meant to trigger on any new issues in the backlog, so that they may receive the New status, so that a team lead can go through them at. This mostly works fine, but the "Status equals Backlog" is not working properly. If I create a new Work Item, and directly gives it the status In Progress, it still matches the filter, as seen in the image below, from the history of a newly created Work Item.

Presumably this is because Jira doesn't actually created the Work Item with the specified status, but rather creates a new Work Item, and then through a separate operation sets the status. Image below is from I created the issue, where it looks like I took a separate action to set the status, but in reality I picked the "In Progress" status in the creation view. I did not manually change it later.

This essentially means that the "Status" cannot be used as a filter in automations for Work Item Created, because it will always have status "Backlog". Is there any workaround to this? It's very annoying, and we frequently have issues ending up with status "New" even though it's already being worked on.

[Christos Markoulatos -Relational- · Accepted solution]

Hi @Fredrik Jonsén welcome!

add a re-fetch

Trigger: Issue created

Action: Re-fetch issue data

Condition: Status = Backlog

Action: Transition to New

[Fredrik Jonsén]

Tried it now, and seems to work perfectly. Thanks for the quick answer.

[Christos Markoulatos -Relational-]

np @Fredrik Jonsén thats what the forum is for. remember when an automation starts it takes a snapshot of the current status, if there are changes in your logic u have to do a re-fetch.

[Bill Sheboy]

Hi @Fredrik Jonsén and @Christos Markoulatos -Relational- 

This symptom is a long-known, racetrack timing defect with the Work Item Created trigger, among other triggers...

When the issue-created event fires, the rule can start before the work item is in a stable condition. 

In some cases, the missing data can cause missed conditions or rule errors, such as incorrect permissions.  In other cases, the work item may not even have a type yet, leading to truly strange errors in the log!  This symptom can also happen with at least the work item linking triggers, the generic work item updated trigger, and the multiple event trigger.  It may also happen with other triggers when the event was caused by another rule.  (For example, one rule edits a work item field and another rule is triggered on changes to the field.)

There are two mitigations for this defect to help manage it, but not always fix it:

• Always add the Re-fetch Work Item Data action immediately after such triggers as Work Item Created.  This will slow the rule slightly, reloading the data before the steps proceed.  Other answers may suggest adding the Delay() action, but that will not help as it does not reload the data.
• Never add conditions directly to triggers such as Work Item Created, and instead add them as separate conditions after the re-fetch noted above.  There are several other defects for adding conditions directly to triggers, but in this case the problem is the data: the conditions may give incorrect results.

The Atlassian team knows about this defect, and for several years has posted about making architectural changes to the automation engine to address it...and, has not provided timeframes for any solutions.  Thus, I recommend always using the noted mitigations.

Kind regards,
Bill