nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Inconsistent Automation rule operation

Owen Guion

I have two similar automation rules and recently a post-function to copy 3 custom fields from an issue's epic to the child
1) on create
2) on update

The post-function in JMWE use is "part of epic link"

Recently the automation rules started being inconsistent in that some time they fire and sometime fail the initial epic link is not empty condition.

Sometimes only one of the three fields is set in the child.

Accepted answers

Bill Sheboy

Hi @Owen Guion

There are known race-track conditions/defects in automation where the trigger can fire the rule before all data is available...primarily with the issue created trigger.

As a result, data like Epic Link may not be populated in time when you try to test it with a condition. The symptom this will manifest is the rule will look like it fired and didn't process anything.

My work-around for that one is immediately after the trigger, add an action for Re-fetch. This will slow down the rule and reload the information before proceeding.

If you do not believe this is the case, please post images of your rules and the audit log from the executions. That may provide more context for the community to offer ideas. Thanks!

Best regards,
Bill

All comments

Melo_45tw58

Hi Owen,

You should be able to check what's happening on the rule audit log

https://support.atlassian.com/jira-software-cloud/docs/debug-a-rule/

If you want to share a screenshot we can look at it together

Cheers,

Melo

Owen Guion

Melo,

I did actually review the automation audit log prior to posting here.

I have instance where the rule execution reports Success, yet the child issue does not have any data in the fields from the parent epic.

Regards,

Owen

Bill Sheboy

Hi @Owen Guion

There are known race-track conditions/defects in automation where the trigger can fire the rule before all data is available...primarily with the issue created trigger.

As a result, data like Epic Link may not be populated in time when you try to test it with a condition. The symptom this will manifest is the rule will look like it fired and didn't process anything.

My work-around for that one is immediately after the trigger, add an action for Re-fetch. This will slow down the rule and reload the information before proceeding.

If you do not believe this is the case, please post images of your rules and the audit log from the executions. That may provide more context for the community to offer ideas. Thanks!

Best regards,
Bill

Owen Guion

Thanks Bill

I inserted a re-fetch and automation is working more consistently now.

Bill Sheboy

Awesome! I am glad to learn that helped.

Please note that re-fetch will slow rule processing by at least a second or two. When trying to see if timing is causing this type of problem in the future, consider first adding a write to the audit log with the data you are testing in the condition. If the data is missing (or not changed as you expected), there is a timing problem to manage.

__Bill

Dave Ung

The problem with the re-fetch here due to it being an actioned performed the rule shows success even though it may not pass the condition afterwards...which should show "no actions performed"

If only there was a pause for like 5 second action instead!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud