How can I make an automation rule more performant?

[Danny]

Hello Community, 

I thought I would throw this out to the Atlassian Community hive mind to help me improve. 

The problem

I have a JSM Cloud project that relies on an approval to be handled by a single user depending on the department that "owns" the request, e.g. HR, Legal, Ops.

Departments are listed in a cascade field, which has multiple child values underneath every department. 

On creation of the request, the creator selects which department they are putting the request against. 

Each Department has an owner. An active request needs to have an approval from the appropriate department owner that the creator selected. 

Steps Taken

I have set up an automation rule that looks for the department value of a new request and assigns the appropriate department owner to approve. 

Currently, I have an IF/ELSE conditional statement for each department option that the rule loops through. Unfortunately, the rule takes up to 10 seconds to process a run. 

My Question

Can I make this more performant? 

Thanks all for reading my question.

[Stefan Salzl]

HI @Danny ,

How is the department field (especiall the owner) configured? Could you give a screenhot for more insights to that?

I´m pretty sure that processing through your departments with if/else might take a lot of time :-/ Something that came to my mind in this case (without knowing further details, the field configuration, etc.... so it´s more a guess) are smart values and (maybe) variables. Did you think about that way or might that be something that sounds feasable?

Best
Stefan

[Danny]

Hello @Stefan Salzl

Each Department is a parent value in the cascade field. 

The owner is applied from the automation rule. 

Automation 

Trigger

When field value changes: Department & Cost Code field

IF/ELSE Block JQL Condition

status = "budget holder" AND project = PROJ AND "Department & Cost Codes[Select List (cascading)]" in cascadeOption(10020)

Action

Edit field value Approvers

How would smart values or variables be applied in this context? 

Thanks,

Danny

[Stefan Salzl]

Isn´t the cascding list automatically asking for providing/choosing the child value? As soon as I choose the parent value the child list opens. I´m just thinking of the automation purpose as the field/entry anyways has to be clicked away manually after I choose the department.

• does each parent only consist of the owner in the child-option? or are there more than 1 options in the child field?
• how is the owner then identified?

Would definitly help to see your setting to gain a better picture of how the rule should act.

Best

Stefan

[Danny]

Hi @Stefan Salzl

The child is used for cost center codes within the department though the budget holder remains the same.

The automation condition is listening for the parent value to be set. The child values are needed for the support team though not required for the automation rule. 

There are more than one cost code per department. Though the budget holder only needs set at the department level. 

The budget holder is pre-defined in the automation rule. 

Do you want a screenshot of the rule summary page? Does the text above not demonstrate the trigger, condition, and action components of the rule? 

Thanks,
Danny

[Stefan Salzl]

Hi @Danny ,

thanks for your explanation. As there are many different terms and I´m "just" dealing with Jira (and not proficient in that special field) every additional hint is helpful (I am a visual type and get a better understanding when I see the things, though this seems very tricky and to be honest: I´m not sure if my knowledge is sufficient here but I would love to give it a shot).

Best
Stefan

[Danny]

I’ll upload a screenshot of the automation rule. 

thanks for sticking at this. 

[Danny]

[Stefan Salzl]

Hi @Danny ,

as far as I can interpret your setting I can just make a guess of an idea but maybe this is a feasable way:

From my point of you view I don´t see a way without if/else either =/ Still I think performance can be increased:

1. status check
   

   status = "budget holder" AND project = PROJ AND "Department & Cost Codes[Select List (cascading)]" in cascadeOption(10020)

   as far as the reference issue is the trigger issue the status check could be done immediatly after the trigger. As far as I got it the rule should only run for issues in status "budget holder"
2. value check (cascade field)
   As it seems for me within each IF block it´s still a static validation of a value of the cascase list fields. Would it be feasable to check those fields/their values via smart values (which i guess is more performant than executing a jql)?
   
   Parent:

   {{issue.fields.Cascade.value}}

   
   Child:
   

   {{issue.fields.Cascade.child.value}}

   
   so if value of parent = 'xxx' and value of child = 'yyy' --> action (budget holder = 'abc')

Hope I got your setting and requirements as correct as possible. If not and you would like to stick to the topic I would have one last suggestion (if possible) to also send a screenshot of how the issue looks like.

Looking forward to your feedback.

Best
Stefan

[Danny]

Helllo @Stefan Salzl

If an IF/ELSE block is being applied though using smart values instead of JQL how can we be sure there is a performance improvement? 

Your assessment for point 1 is correct. Your assessment for point 2 is partially correct; the check should only look at the parent value, the child value is immaterial with regards to the trigger. 

I would love to test this though I am unsure how to set up a trigger using smart values. Are you able to advise if at all possible? 

Hmm, screenshot of the issue. 

[Stefan Salzl]

Hi @Danny ,

If an IF/ELSE block is being applied though using smart values instead of JQL how can we be sure there is a performance improvement? 

This is just my intention and what I´ve read so far in the community posts that smart values perform better than processing jql. Guess the only way to "be sure" is to build 1 rule with jql and 1 with smart values and compare time of processing.

---

the child value is immaterial

That was my first guess and would even save another check in the condition (from my point of view).

---

how to set up a trigger using smart values

Could you explain this a bit in detail? Trigger can be several issues or events on issues/in the system. Smart values then can refere to those "entities". eg.:

• as already pointed out in one of your former posts the trigger event is "value change" in special field
• therefore as soon as the rule is triggered the information/entity of {{issue}} is provided to that run --> the {{issue}} in which the value was changed/which triggered the rule
• smart values within the rule/run then refer to the delivered {{issue}}

Looking forward to your feedback.

Best
Stefan