Trigger conditions with forms not triggering correctly?

[Austin Powers]

I recently noticed that trigger conditions are now active in our Jira cloud instance and tried to move some conditions, that originally were right after the trigger, inside the trigger action itself.

I noticed that most of them work as expected. Like work item changes and transitions. Now I might have encountered a bug or an edge case that I could not find on https://support.atlassian.com/cloud-automation/docs/what-are-automation-rules/#Conditions-added-to-a-trigger

If I want to check for a submitted or locked form in the "Work item created" trigger, it does not pass the condition. No matter which form I'm choosing. My guess is, that this is the wrong trigger for our case, but it seems strange that you can check for this condition inside the trigger, if it does not work that way.

To give a bit more detail on the workflow:

HR goes to our Service Desk homepage and chooses the "Employee Offboarding" request type. This request type only has a form attached to it, which in turn is connected to some request fields.

Upon entering all the details into the form, a work item is created by the Service Desk.

Here is where the automation should start.

1. Trigger = Work item created
   
   1. Condition: Request Type = Employee Offboarding
   2. Condition: Forms attached - Specific forms attached to the work item (Employee Offboarding form) - Submitted or locked
2. Start adding Asset information according to the Forms details

-----

As mentioned previously. Those conditions work without an issue if they are right after the trigger. As soon as they are a part of the trigger action, the automation does not continue.

Any input on what I'm doing wrong would be great. Because those rules "fail" silently. Meaning they execute with "No actions performed"

[Marc - Devoteam · Accepted solution]

Hi @Austin Powers 

Welcome to the community.

To me this seems like a bug, as conditions can't be checked if the work item/issue doesn't exist yet.

And indeed this is a BUG, its already. marked as a bug, AUTO-2007 

[Bill Sheboy]

Hi @Austin Powers -- Welcome to the Atlassian Community!

Yes, and...to the information from @Marc - Devoteam 

The cause of this symptom is a long-standing, racetrack timing problem with some rule triggers, such as Work Item Created.  Specifically, the rule can start running before all of the data is available, or the item is even in a stable condition.  This can appear as weird rule errors (e.g., permission problems, no issue type!, etc.) or conditions not matching as expected.

Thus, adding conditions to the trigger will further hide this problem.  In the announcement for this advanced component feature, I asked the Atlassian team member about it and...they know about it, they are working on architectural changes to fix it, and there is no time frame for when this will be fixed.

Given that uncertainty, I have two recommendations:

• As other triggers can have this racetrack timing problem, perhaps do not use that new feature to add conditions to triggers yet.  I advise this because the audit log does not show why a rule did not trigger with this new feature (yet).  This will conceal any problems of a work item did not match the condition, versus the timing problem.
• With the Work Item Created trigger, add the Re-fetch Work Item Data action immediately after the trigger, then followed by any conditions.  This will slow the rule slightly, reloading the data before the steps proceed.

Kind regards,
Bill