How do you set the value of a smart variable in an automation

[jeremyn]

Hi All,

We have an automation that we wrote which is having some issues and I am looking at how to fix it. 

The automation triggers on any of three custom fields changing, does a math calculation on them and sets a fourth field with the value as it goes through the inputs. But we are getting bad results when a user changes the thee input params in quick succession (which is common)

Currently it is something like this:

When A, B or C changes

Set D = 1

IF A = high { D = 5}
Else if A = Med {D = 3}

re-sync 
IF B = High {D = D*5}
Else if B = Med {D = D*3}

re-sync 
IF C = High {D = D*5}
Else if C = Med {D = D*3}

So our idea is to create a smart variable and set its value as we do the calculation(s) then at the end set "D" to the smart variable's value.

Like this:
When A, B or C changes

create {{DVar}} = 1

IF A = high { DVar= 5}
Else if A = Med {DVar= 3}

re-sync 
IF B = High {DVar= DVar*5}
Else if B = Med {DVar= DVar*3}

re-sync 
IF C = High {DVar= DVar*5}
Else if C = Med {DVar= DVar*3}

set D = {{DVar}}

I can create the smart variable, and I can set the field to the smart variable, but for the life of me I can't figure out how to update the smart variable value.

Essentially we are looking to mutex the calculations so parallel automations won't result in bad results.

Any suggestions or input is much appreciated

[Bill Sheboy · Accepted solution]

Hi @jeremyn 

First thing, there is no feature yet to edit a created variable within an automation rule; you can only recreate it with the same name.

Next thing, how fast is "quick succession" for the changes to fields A, B, C?  Is this over minutes or seconds as someone is just changing the values, moving between fields?

If these are changed in "seconds" the rule will probably trigger in rapid succession and potential have multiple intermediate results...not matching what you expect...until the final execution completes.

Looking at the calculation you describe, I suspect you can perform this calculation in one step, using a math operation nested around conditional logic.  That will both speed up the rule and give you an opportunity to reduce the number of calls to Re-fetch issue (each of which takes a bit of time).

For example...

• trigger: Issue field changed for field A
• action: Re-fetch issue
• action: edit issue to set field D

{{#=}}( 0{{#if(equals(issue.fieldA,"high"))}}4{{/}}{{#if(equals(issue.fieldA,"Med"))}}2{{/}} + 1 ) * ( {{#if(equals(issue.fieldB,"High"))}}5{{/}}{{#if(equals(issue.fieldB,"Med"))}}3{{/}} ) * ( {{#if(equals(issue.fieldC,"High"))}}5{{/}}{{#if(equals(issue.fieldC,"Med"))}}3{{/}} ) {{/}}

Notice that I updated your fieldA tests to account for the default of 1 by adding values of 4 or 2, rather than replacing the value.  You could instead set the default if fieldA has a value "low" which defaults to 1.

Also also notice I only triggered on field A, as Jira Cloud automation does not support multi-field checks on edit, like with Server/Data Center.  The work-around is to use the generic Issue Updated trigger and add condition tests for which fields changed by the edit using the changelog.

The key for calculations like this breaking them down into pieces, and testing by writing to the audit log before making any edits.

Kind regards,
Bill

[jeremyn]

Hi Bill,

This is very helpful, thank you. It is rather disappointing that we don't have a way to mutex an automation to help assure we can run more complex work in one pass.

Yes, the users are changing the values in the order of seconds, typically our SMEs are when they triage the bugs and update the fields from the initial reporter's guesses.

We are seeing "permanent" issues with the calculations if one run makes a change between the resync and the calculation of one of the other runs, which is where the real issue lies. If it was self-correcting once all the runs finished that would be OK.

I did simplify the example for the sake of brevity, each field has either 5 or 6 values, so yes we could use the default "low".

[Bill Sheboy]

With the current features of rules, the only work-arounds for the multiple execution I can think of are:

• make the rule run on a schedule rather than on field-change; clearly that is not ideal
• use a manual trigger for the rule

[jeremyn]

For completeness if anyone else runs into a similar issue:

Following your recommendations I did the following:

1. I used the trigger "Value Changes for" and selected all three of the params we care about
2. Refetch data
3. Our issues are single select custom fields, so we needed to use .value in the compare. I also liked the idea of using a +1, since we do have one param with two weights of "1".
   {{#=}}
   ( 0
   {{#if(equals(issue.fieldA.value,"Option E"))}}4{{/}}
   {{#if(equals(issue.fieldA.value,"Option D"))}}3{{/}}
   {{#if(equals(issue.fieldA.value,"Option C"))}}2{{/}}
   {{#if(equals(issue.fieldA.value,"Option B"))}}1{{/}}
   + 1 ) *
   ...{repeat for each field}
   {{/}}
   
   

So far this design is between one third and half the time as the other one, and I have not been able to reproduce the issue. The lack of a required re-sync between steps seems to be the key to preventing the condition we had before where we needed a resync in order to re-use the previously calculated parameter.

So even if the possibility exists, it appears that the window is now much smaller.

Thanks again for the insights Bill

[Bill Sheboy]

I am glad to learn that helped, and...

It seems the feature of detecting multiple field changes as a trigger has been added for Jira Cloud.  Previously this was only in Jira Server/Data Center with Cloud only supporting one field at a time  :^)