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

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


1 badge earned


Participate in fun challenges

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


Gift kudos to your peers

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


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!


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
Community Members
Community Events
Community Groups

Getting the average of multiple custom number fields in the same issue


In Jira Server, I'm attempting to calculate the average of several number fields within the same issue. As a starting point, I've tried using the '+' operator to see if I could simply sum all the values and I can't even get past that hurdle. That attempt looks like within the edit issue action:

{{#=}}{{issue.Evaluation of Exposures}} + {{issue.Renewal/ARR Pricing}} + {{issue.Communication to Agent}} + {{issue.Issue Instructions/Renewal Pricing Sign Off}} + {{issue.Risk Grouping}} + {{issue.Deductible}} + {{issue.Claims Information}}{{/}}

That's returning the following error: Unknown unary operator '{' at position 1:

The other approach I've found googling the topic is to use the appropriate numerical operator, but every example I've found seems to assume there will only be two values involved and I'm unsure if it's possible to use the syntax presented with more than two values.

Any thoughts are greatly appreciated!


2 answers

1 accepted

2 votes
Answer accepted

Hi @Rick Crow 

I wonder if it is because you have the reserved character / in the names of the custom fields.  Please try to replace the names for those fields with the custom field ID values instead to see if that works.

You may find those IDs from the admin functions or you can quickly just call the REST API with an example issue to see all of them at once.  Here's the how-to for that:

Kind regards,

Hey, @Bill Sheboy ! Thanks for the suggestion. I just tried that and I'm unfortunately still getting the same error.

I should also mention (I'll update my original question text) that this is within a Server instance. We're in the process of migrating to cloud, so if there's a better solution there, I can shift to solving for that context rather than server.

Like Stefan Salzl likes this

Thanks, Rick.  The next thing to check is if the field types are numeric, as Stefan notes.  If not, try converting each one with asNumber with a default of zero, such as:

{{issue.Evaluation of Exposures.asNumber|0}}

Like Stefan Salzl likes this

Thanks for the direction. I had assumed these were number fields, but now see they're Deviniti Dynamic Forms select fields. These fields all have the same options:

  • N/A
  • 1
  • 2
  • 3

@Bill Sheboy, I've followed your direction and modified the script as indicated. I'm no longer getting an error, but the resulting value is "0" and should be "18" as there are 7 fields with these values: 3, 3, 2, 2, 3, 2, 3.

I've limited the automation to a single issue initially for testing purposes to ensure that no issues in the automation's scope would have a value of 0, or be empty.

As we prepare for migration, these Deviniti fields are being replaced as there is no corollary in the cloud, so if that ends up being a problem, the cloud version of this form will be using either standard number fields or standard select fields.

@Stefan Salzlthere are only two elements to the automation at this point:

  • A scheduled trigger using a jql query: issuekey = UWADT-1504:

Screen Shot 2022-05-06 at 11.35.04 AM.png

  • An Edit Issue action with my target number field identified as the field to modify with the script in question populating that field:

Screen Shot 2022-05-06 at 11.33.43 AM.png

Like Stefan Salzl likes this

Here is one hypothesis: fields for addons which dynamically generate values cannot be used in smart value expressions other than as a simple read due to the order of operations.

How to test that: write {{issue.Evaluation of Exposures}} to the audit log and see if it has a value.

@Bill Sheboy Thanks for the additional thought. Since I can't use those going forward, I'm moving ahead with the assumption I'll be using either standard select or number fields in the cloud version of this screen. 

I had already created and copied values into the standard version of each of these fields and I've now added those to the screen and modified the script to refer to them rather than the Deviniti fields. While I'm still not getting an error, I'm still getting a response of 0 (zero) in my target field.

@Bill Sheboy Update. For grins, I used your test and wrote both {{issue.Evaluation of Exposures}} and {{issue.Evaluation of Exposures nd}} (the modified, non-dynamic field). As expected, the first one returned significantly more than the field value and the second one returned the value of 3. I then modified the first one to {{issue.Evaluation of Exposures.value}} and it then also returned the correct value of '3'. But neither approach is yielding a correct sum from the automation.

@Bill Sheboy Update: using either {{issue.Evaluation of Exposures.value}} (Deviniti dynamic selects) or {{issue.Evaluation of Exposures nd.value}} (standard select fields), I'm now getting a valid sum.

Finally then, I've modified the script to divide that sum and I'm now good!

{{#=}}({{issue.Evaluation of Exposures nd.value}} + {{issue.Renewal/ARR Pricing nd.value}} + {{issue.Communication to Agent nd.value}} + {{issue.Issue Instructions/Renewal Pricing Sign Off nd.value}} + {{issue.Risk Grouping nd.value}} + {{issue.Deductible nd.value}} + {{issue.Claims Information nd.value}}) / 7 {{/}}

Thanks for helping point me in the right direction.

Like # people like this

I am glad to learn that worked.

Often the trick in getting an automation rule to work is using the correct smart values (name, capitalization, spacing, etc.)  This how-to article may help find all of the available smart values, and their respective custom IDs, for an issue:

0 votes
Stefan Salzl Community Leader May 06, 2022

Hi @Rick Crow ,

Could you maybe provide a screenshot of the automation rule? that would give us the possibility to see the whole scope/context and eventual other settings that might affect the rule.


- Could you please re-check and confirm that all the required fields are of type number?

- Is it granted that ALL fields are filled with value? Otherwise I would suggest to use defaulz value 0 in case of an empty field because an empty field would break the calculation (as far as I know).


Suggest an answer

Log in or Sign up to answer

Atlassian Community Events