Automation Help

[Tyler Cassar]

Hi guys, I am trying to create an automation that does the following -

Let's say there is 20 components held on the (Compass Components List) -

• 10 of them are "High Risk" with a value of 10 points.
• 5 of them are "Medium Risk" with a value of 5 points.
• The remaining 5 are "Low Risk" with a value of 1 point.

I am trying to make a manual trigger automation that automatically calculates the total score of their risk based on the fact that no matter how many of those "Components" of a specific risk level are added, their value is only considered once. 

So High Risk + High Risk + Medium Risk = 15 Points not 25.

So far, I've encountered a stumbling block in attempting to use an Automation to calculate this score -

If I use branching and set up an IF Condition saying if High Risk Component is selected, then create a variable called HighRiskScore with score 10. And then a second branch saying if Medium Risk Component is selected, then create a second variable with the score of 5. And ask them to output at every branch, I get a total value of 0. Meaning that when I then try to calculate the total score, I also get 0.

If I use If / Else conditions, I block out the possibility for it to advance down the chain of IFs by having the first condition met. And if I use just an IF condition followed by action, followed by a next IF, it skips all the points underneath the original IF.

Does anyone know what I can do in this situation? I've attached a crudely drawn diagram of how I want it to act below.

[Bill Sheboy]

Hi @Tyler Cassar 

For a question like this, context is important for the community to help.  Please post the following:

• an image of your complete automation rule in a single image for continuity
• images of any relevant actions / conditions / branches
• an image of the audit log details showing the rule execution
• explain what is not working as expected and why you believe that to be the case

Until we see those...

How are you associating a risk indicator / score to the Compass Components?

Let's assume you are using the component's name to identify "risk level" and then using that to map to the scoring.  If so, there are at least four ways to do this:

1. Flatten the list of Component names, chain together 20 replace() function calls to translate to Low / Medium / High, split the values and use distinct to reduce them, and finally replace again to convert to numbers for the score.  This may be very difficult to maintain as I expect it can be done in a single smart value expression.
2. Iterate over the Component names with the long-format iterator, using conditional expressions to translate them to Low / Medium / High (or directly to the numbers), storing the result in a created variable, before splitting the variable to use the distinct function to reduce them before summing the result.  This will be slightly easier to maintain.
3. After first creating placeholder variables, use a series of if / else condition blocks to update the variables if any Low / Medium / High component values are found, and after the if / else blocks, use a lookup table and math expression to sum the score.  This will be a very long rule (nearly up to the maximum size limit), and so easier to understand but also difficult to maintain due to the rule length.  This is similar to what you are already trying.
4. Hack: add the Low / Medium / High indicator to the names of the components (e.g., "Squirrel_component_High_Risk"), and then use text functions to extract the indicators, add distinct, and quickly get to the result.  This seems like a brittle, bad idea for several reasons.

Kind regards,
Bill

[Maksym Babenko_TypeSwitch_]

Hey @Tyler Cassar

This sounds like a classic case where automation starts to hit its limits, especially with conditional logic and branching.

If you're open to trying an app, you might find Risk Radar helpful.



It’s a lightweight tool that lets you assign risk levels (e.g., High/Medium/Low) and automatically calculates a risk score per issue without needing to set up complex automation rules.

Each unique component type (or custom field value) is only counted once in the score logic, just like what you're aiming for.

It might save you time and give your team a consistent, visual way to manage and communicate risk.

Hope that helps!

[Bill Sheboy]

Hi @Maksym Babenko_TypeSwitch_ 

As a reminder...when recommending a marketplace vendor product, please ensure you disclose your affiliation to that vendor in your post wording, and not just in your profile name / badge. For more information about this, please see:

Atlassian Partners - Rules of Engagement

https://community.atlassian.com/t5/App-Central-articles/Atlassian-Partners-Rules-of-Engagement/ba-p/2899328

Kind regards,
Bill

[Alexander Hohmann]

Could you use "IF ... ELSE IF" instead of "IF ... ELSE"? That way, the rule should keep going since the conditions are reevaluated at each "ELSE IF"-node.

[Tyler Cassar]

Pardon my ignorance, how would I do that?

[Alexander Hohmann]

Underneath an existing IF condition, click on "ELSE". If you add at least one condition in the ELSE node, the 'ELSE' should turn into 'ELSE IF'. Otherwise it remains an unconditional 'ELSE'.

[Tyler Cassar]

Wouldn't that still lead to conditionals being missed?

• IF Component is not Empty
  • Apply Action
• IF ELSE Component is not Empty + Component = High Risk
  • Apply Action (Log Variable)
• IF ELSE Component is not Empty + Component = Medium Risk
  • Apply Action (Log Variable)

Wouldn't that mean if I had a High Risk + a Medium Risk, since there was an action taken on High Risk, it would just auto ignore the Medium Risk?

Or do I need to build it in a IF High Risk + Medium Risk + Low Risk, and all the combinations combined?

[Alexander Hohmann]

You certainly have a point there. And right now I cannot think of something more elegant than going through several combinations. You could use the 'contains' or 'contains none of' condition for the 'Components' field, or work with the 'IN' operator in JQL: 'component in (value 1, value 2, ...), or the NOT IN or the CONTAINS or the DOES NOT CONTAIN operators. Sorry. If I can think of something more elegant, I'll add it here.

[Alexander Hohmann]

One more idea: you could create three rules instead of one, and have the first one (the manually triggered one) do something that then triggers the other two (like modifying a field, perhaps a hidden one), each rule checking only for components of one type. But that will cost you three units off your rule count, which may be limited depending on you Jira license plan.

[Tyler Cassar]

I actually came to the same conclusion to get the final risk scoring funnily enough.