How do I correctly use Automation with Original Estimate?

[Aron Kuch]

I want to use automation to change the Issue Type based on the Original Estimate field. There are four options/levels.
For the If and Else-if blocks, I tried using Issue fields conditions, but Original Estimate did not appear in the list Field. I tried the Advanced compare condition (the "If: matches" in the graphic), but it did not trigger and I tested 350h, 350 and 350*3600. Last I tried JQL condition (the "Else-if" in the graphic) which worked but could take up to 2 seconds according to the audit log. The audit log also included the line "We recommend using the 'Issue fields condition' for more consistent results."
Am I doing this right? Is there a better, more efficient way?

[Trudy Claspill]

Hello @Aron Kuch 

Before diving into trying to find a solution, can you confirm that the types of the issues that would be the source and destination types all use the same workflow? If they don't use the same workflow then your attempts to change the issue type are likely to be unsuccessful.

[Aron Kuch]

Yes, all the available issue types use the same workflow.

[Trudy Claspill]

Can you show us the audit log associated with the rule execution?

Can you add Log actions to print out to the Audit Log the values of the smart values you are using in your comparisons?

[Aron Kuch]

I added some Log actions. Let me know if these details are helpful.
I suspect my previous attempt to use the time as 350*3600 didn't work because I needed to make that a math smart value, i.e. it wouldn't automatically calculate. Or I could calculate 1,260,000 and use that value, which is what I'm going to try.
This also showed why I was having trouble when first assigning a value to Original Estimate, because the fieldChange was timeestimate not timeoriginalestimate. I'll need to figure out how to handle an OR. 

[Mykenna Cepek]

Several initial thoughts here...

• JQL conditions will be slowest; definitely use Field Conditions whenever possible.
• The "Log action" rule component can really help when debugging rules. See below.
• My tests were in Jira Data Center, not Jira Cloud. Your results may vary.
• Sometimes Jira stores "time tracking" values in seconds, sometimes as text.

That said, let's see if you can reproduce the beginning stages of trying to work out what's going on. I created a test rule like so:

Here's how the trigger is configured:

And here's how the log action is configured:

When I change the value for the "Original Estimate" field in an issue, the rule executes and I see this in the rule audit log:

Let's make sure you can get this far. Or maybe this is enough to get you going?

[Aron Kuch]

Unfortunately, perhaps because of using Cloud instead of Data Center, I cannot choose Original Estimate for Field to monitor for changes.
So I used the workaround from another community post.

[Aron Kuch]

I changed the compare so that it includes both fieldsChange.field options(1), and switched back to Advanced compare conditions from the JQL, with math expressions(2). It's running better, close to 1 second.

Yet the work around for Original Estimate seems weird. I guess that's just the way the field works.

(1) https://confluence.atlassian.com/jirakb/automation-how-to-compare-smart-value-with-list-of-options-in-advanced-compare-condition-1223822374.html
(2) https://support.atlassian.com/cloud-automation/docs/jira-smart-values-math-expressions/