Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,465,356
Community Members
 
Community Events
176
Community Groups

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

Edited

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

1 answer

1 accepted

3 votes
Answer accepted

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

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".

Like Bill Sheboy likes this

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
Like jeremyn likes this

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

Like Bill Sheboy likes this

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  :^)

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
TAGS

Atlassian Community Events