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

3 Jira automation rules we will cover in our advanced webinar

Hi all,

Next week we will be running an advanced automation webinar called ‘How to supercharge your automation in Jira Cloud’. This is the second in our series and this time round, we will focus on 3 powerful use cases. Andreas, who co-built the automation engine and loves sardines, will walk through the 3 use cases below, explaining how it all works in detail. For those who want to examine the rules at their own pace, I will post the 3 rules here also.

Before I do here are other resources that might help:


The rules we will cover in the webinar

Rule 1: Send Slack message notifying about all open issues in Sprint

rule-lookup-issues (1).png

In this rule, we are going to use automation to send a Slack message showing all of the open issues left in the sprint. We will be using our brand new ‘Lookup issues’ action that allows you to create reports and notifications for a number of issues.

It can send a daily report of outstanding issues in the current active sprint to Slack. We will also get into the nitty gritty and show you how to use list iteration syntax in smart-values to iterate over a collection of issues (e.g. {{#lookupIssues}} {{key}} {{/}})


Rule 2: Sum up story points and keep parent and sub-task in sync



This is a new twist on a familiar and common automation rule. Again, we are showing off some new functionality - the ability to aggregate math functions in smart-values. In this instance we show you how you can sum up story points of all sub-tasks and update the parent issue with this value whenever a sub-task's story point value changes

This rule uses a related issue branch to navigate up to the parent issue of a sub-task, and then uses the following smart-value to sum up story points from all sub-tasks: {{issue.subtasks.Story Points.sum}}


Rule 3: Notify dev team on PR merge


The feedback from our first webinar was ‘give me more juicy and complex use cases’. Well, Andreas has taken you at your word and this powerful rule is the result!

Again, we will showcase a new feature - our new DevOps triggers, which you can use with BitBucket, GitHub or GitLab. Even if you don’t use a git provider, this this rule will teach some valuable lessons. You can just change the components in and out as suits best.

In this rule, we will react to PR merged events and then notify the Dev team. We will then take this a step further and show you how to build a custom integration with a Jenkins build server using our 'Send web-request' action.

Lastly, this rule showcases that you can even use responses from a third party service (like Jenkins) to perform further actions in Jira! Told you we would dive deep!

It may look intimidating but we will break everything down into bite sizes during the webinar so it is all clear.

We look forward to seeing you all at the webinar! If you haven't already registered, do so now!

John & Andreas

Automation team



This is the link to the blog where we explain all of the new smart value functionality:

There were also a few calls in our Australian webinar to include the smart values. You can find all of these in our docs. However, to keep it all in context, I have popped them below also: 


Rule 1:

These smart values will list all of the open issues (with url) and send them to Slack in bullet point format:

Hey team, we’ve got the following issues left in this sprint {{#lookupIssues}}




Rule 3:

These smart values @mention the assignee and inform them of the issue that has been merged.

Hey [~accountid:{{assignee}}], This issue ({{issue.key}}) has now been merged.


This smart value shows the PR url and title and adds a rocket emoji.

We just merged PR: <{{pullRequest.url}}|{{pullRequest.title}}> :rocket:


Lastly, this smart value simply adds a value to the audit log {{webhookResponse}}

Great work guys :)

Like John McKiernan likes this

Has the {{#lookupIssues}} smart value been added to Jira Cloud. I'm attempting to use it and get one email for every issue in the query with no issue data in any email.

Screen Shot 2020-06-17 at 1.02.47 PM.png

Curt Holley Community Leader Jun 17, 2020

I got this tip yesterday. Try something like:

<li>{{key}} - {{summary}}</li>

Thanks for the tip, but I'm still getting multiple blank emails (one for each issue in the result).

<html><head><meta http-equiv="Content-Type" content="text/html; charset="utf-8"></head><body>Hey team. Here's the current status of tickets in the QA Release Candidate.<br><br><ul><br></ul></body></html> 
Sam Harding Atlassian Team Jun 17, 2020

Hi Bryan, from the screenshot above, it looks like the rule does not have the 'Lookup Issues' component in its component chain. The Lookup Issues action only defines the {{lookupIssues}} smart value for the Automation rule it is added to, so every rule which wants to use the {{lookupIssues}} smart value must have the 'Lookup Issues' component added to it.

The solution for your use case would be to add the 'Lookup Issues' action after your 'Scheduled' trigger, and before your 'Send Email' action. Let us know if that works for you.


Like # people like this
Curt Holley Community Leader Jun 17, 2020

Good spotting @Sam Harding 

Curt Holley Community Leader Jun 17, 2020

Question: With "Sum" up Story points, is it likely that in the future we will be able to use this to Sum up Story points on "Stories" etc. into their Epic?

Sam Harding Atlassian Team Jun 17, 2020

Yes, summing up story points is one of the most desired use cases for this feature. We have a number of fields/properties we will be adding to this shortly, with sum up story points being one of the first that will be rolled out.

Like # people like this


I tried to use the rule 2 (sum up story points...) to sum up "Original Time Estimate" but did not succeed. Am I trying something that is not possible or should I just try harder?

Hey @Santeri Huvinen ,

It should work for you. You can learn a little more about it in this post:

Otherwise feel free to post a screenshot of your rule here and we can look into what might be going wrong :)



Like Santeri Huvinen likes this
Curt Holley Community Leader Jun 18, 2020

Hey @John McKiernan  

Do you know if I can (or will be able to in the future) sum up custom numeric fields?

Use case is: The ability to do WSJF calculations in Jira with the help of Automation for Jira. 

Value + Criticality + RR OE = Cost of Delay

Cost of Delay / Job Size = WSJF

Like Carlos Piqueres likes this

Hey @Curt Holley 

You should be able to do this. I have attached a screenshot to show how it might work. Let me know if any issues

image (22).png

Like Curt Holley likes this
Curt Holley Community Leader Jun 18, 2020

Thank you very much @John McKiernan 

@John McKiernan Thanks!

Now I got my automation working with triggers "When: Issue updated" and "When: Manually triggered", but the trigger "When: Field value is changed" does not work for me. There must be a problem with matching field name "original estimate". I did try "original time estimate" too. I wonder why that field cannot be found from the drop-down list.


Hey @Santeri Huvinen

Is this rule in a next-gen project? Also just checking - are you using any third party apps for this field?



@John McKiernan the rule is not in a next-gen project. An yes we are using Tempo for time tracking and reporting. However, I'm not sure if Tempo is using this particular field (original estimate).

Hmm I am not sure @Santeri Huvinen 

If it is not a Tempo field, it should work fine. This would be one for the engineers to take a deeper look into. Would you mind taking a screenshot of your audit log as well as the rule and putting it through to the support team? 



@John McKiernan There is not much to see in the audit log since my rule does not ever get triggered (with "value changes for original estimate (match)") . But I can send the screenshots. So putting it through to the support team means creating an issue here

That's right Santeri. Apologies, as a non-Dev, I don't want to waste your time so best to cut straight to the experts when I am not sure :) 

Like Santeri Huvinen likes this


I have used the automated Sum function to update the parent cases remaining estimate field when the child case is updated.  It is changing the time I have recorded as seconds but then saving this as hours.  Eg. I have put 2 days remaining on the child case and it has saved this as 36,000 hours remaining against the parent case.



Hey Lucy, 

Jira's default time stamp is in minutes so you will need to add a little math smarts to it. You can see more on this page which will help you:

Hope that helps


Like Lucy Cookney likes this


 Can I do a SUM function on a filtered list? Scenario: Sum Story Points of all sub task that are not Done.

I can't seem to get the filtered list working. I've tried nesting a math IF function, regex string matching on the collection, and Lookup Issue. I couldn't get any of these methods working in from a variety of syntaxes and permutations. 

BTW, thx for the webinar! @John McKiernan  & @Andreas Knecht . Great stuff!

Hey @JasonB3 ,

Glad you enjoyed the webinar! Always fun running one. 

At the moment, this is unfortunately not possible. It is an existing 'bug' / limitation :

The good news, however, is that it is being worked on by one of our engineers at the moment so it should be working within a few sprints. Hesitant to give an exact date but I'll update this post once shipped. 

Hope that helps!


Hey @JasonB3 ,

good news, you should be able to do this now. 

Any of these smart values should work: 

  1. {{lookupIssues.Story Points}} 
  2. {{lookupIssues.Story point estimate}}
  3. {{lookupIssues.Story Points.sum}}
  4. {{lookupIssues.Story point estimate.sum}}

Hope that helps!

Thanks @John McKiernan !

Tested and this works!



The Edit issue fields code is:

"fields": {
"Story Point Estimate": {{lookupIssues.Story point estimate.sum}}


Thanks again

Ah nice, that's a great use case. Thanks for sharing! 


Is it possible to add a comment on the issues obtained through {{lookupIssues}}?

Regards, Ramana.

Hey @Venkata Ramana Kaza ,

yes absolutely it would be as easy as adding one more action to the end of the rule to comment on the issue:

Automation rules - Jira 2020-08-14 10-06-12.pngHope that helps!


Thanks @John McKiernan. But this is adding the comment only on the first issue in the search result. Not on all issues. Is there a way to traverse each issue in the result set and add a comment or perform any other action?

Regards, Ramana.

Ah apologies Ramana, I see what you were asking now. 

I don't believe this would be possible. You can't iterate through a list and comment on each. You could set up a second rule with the same JQL that would leave a comment. Not perfect but it might do the trick.

For example:

  • Scheduled trigger with JQL
  • Add comment to issues

@Venkata Ramana Kaza @John McKiernan : I'm trying to figure the same rule for updating / adding comments to ~100 tests in the Test Execution with the date/ Jenkins build and was not successful so far. Please share your rule setting if you find the way of updating jira issues that returned by JQL.

TIA, Olga

Hey @Olga Buslovich ,

For this question, I think it would be best to pop a question through to our support so one of the engineers can answer it. We might need to get into the weeds a bit :) 


Is it possible to access the Sprint value of the issues in {{lookupIssues}}? I tried {{}}, {{}}, {{}}. But none work! Any pointers / help would be greatly appreciated. Thanks in advance.

Hey @Venkata Ramana Kaza ,

think the value you are looking for is {{}}

You can see the full list in the screenshot below or on this page

If no joy there, can you tell me what trigger you are using (or better again, send a screenshot of your rule) and also whether you are working on a next-gen project?



Screenshot at Nov 13 09-28-31.png

Sam Harding Atlassian Team Nov 12, 2020

Hi @Venkata Ramana Kaza 

John's comment above is how you can access the sprint smart value when using sprint related triggers, so should help you get started with using sprint related automation rules.

Specifically with lookup issues, the sprint field is not supported on lookup issues smart values. This would be the reason your smart values are not working. There are some other ways to work around this depending on your use case, for example a JQL condition could check if the lookup issues sprint match a given sprint name, along the lines of 'id in {{}} AND sprint = 'mySprint'. However, direct access of the sprint info for lookup issues is not possible.



Thanks @John McKiernan and @Sam Harding

I am using Schedule trigger and querying for issues using Lookup Issues action. The JQL in the lookup issues is:

Sprint in openSprints()AND statusCategory != Done

The result set is then being emailed. In the email, I am trying to publish the sprint of each issue using {{sprint}}, but that is coming blank.

Based on your responses, looks like this is not possible.


Log in or Sign up to comment

Atlassian Community Events