Iterate comments on a list of issues

[Oliver Moore]

Hi All,

I want to make sure that my agents are aware of tickets that they have not commented on in the last 48 hours. I currently have the following rule that does this:

This works perfectly, but is burning through my automation quota.

I feel it should be possible to achieve this with a daily job but I am getting stuck with multiple branches.

My pseudo code is:

• Lookup Work items for all issues updated in the last 48 hours
• Branch
  • For each item in the lookup (or alternatively do an advanced branch using the above JQL)
    • Look at the comments (news first)
    • Look at {{comment.internal}} = false
    • Do a lookup to see if the comment author is a customer or not
    • If they are not a customer, update the last comment date.

Where I am getting stuck is iterating a list of issues, and then iterating each issues comments.

Is the above possible, or is there some other approach I'm missing to be able to do this on a scheduled basis?

[John Funk]

Hi Oliver,

I didn't go through the details of the rule yet, but what if you changed the trigger to a scheduled trigger and just ran it a few times a day? 

[Oliver Moore]

Hi John,

Thanks for this - exactly the spark I needed. I hadn't realised the schedule job processed each issue in turn.

I can't use my current rule as the automation "users" tests are not available to test comment authors unless you're triggering the automation based on a comment (in which case you can use the "user who triggered the action".

I'm currently working on a branch over the issue comments to use the comment author to pull the user via API and then parse the web-response body. I'll update here if I get stuck/get it working.

Cheers!

Oliver

[John Funk]

Awesome! Hopefully that will work out for you. 

Using lookupIssues function might also help.

[Oliver Moore]

HI John,

I think I've fixed it as follows (note this is for a service desk project):

1. Get all of the issues in the last 24 hours as a scheduled task
2. Branch and process each comment (in reverse order - newest first - {{issue.comments.reverse}} )
3. Check if you are processing an external facing comment - if yes
4. Get the author of that comments.
5. See if the commentor was automation via the accountType - if yes
6. See if the email address for the account matches our domain - if yes
7. See if the work item "last comment date" is older than the date of the comment (note needing to use JQL as you can't do date comparisons) - if yes
8. Update the work item last comment date
9. Ref-etch the data so the check on 7 works ok

Suggestions welcome on future improvements. I might add a web call to process based on group membership rather than filter via email address, but this will do for now.

Thanks again for the key pointer on the scheduled job behavour.

Regards,

Oliver

[Bill Sheboy]

Hi @Oliver Moore 

For the updated rule you show, I do not believe that will work...

Branches which could be on more than one thing are processed in parallel and asynchronously, with no guarantee of the processing order or when the branch will finish...up until the last step of the entire rule.

That means the branch over {{issue.comments.reverse}} has no control over the actual order.

After helping with other questions similar to this scenario, I suggested a possible workaround:

• remove the branch
• iterate over the comments and use smart value, list filtering to store the comment date which are internal in a created variable (or any other criteria you want to use) with a delimiter
• split the variable back into a list, convert the text with toDate, and get the maximum date value for the latest one
• use that maximum date where needed

Kind regards,
Bill

[Oliver Moore]

Hi Bill,

Thanks for that insight. I've redesigned it as follows:

1 - Check if issue has comments - {{issue.comments.size}} > 0

2 - pull all the external comments in reverse order that end with "@my.email" to a variable

{{#issue.comments.reverse}}
 {{#if(not(isInternal))}}
  {{#if(author.emailAddress.endsWith("@my.email"))}}
   {{created.jiraDate}}{{^last}},{{/}}
  {{/}}
  {{/}}
{{/}}

 3 - Check the variable is not empty

4 - split the variable on "," and update the "last comment date" to be position "0" (as 0 will always be the most recent date) - {{commentDates.split(",").get(0)}}

Any thoughts on this - I was slightly concerned the nested "if" wouldn't work but it seems fine.

I also found that when iterating issue comments, Jira can only cope with 100 max.

Regards,

Oliver

[Oliver Moore]

Actually - it looks like the "last" in point 2 is not working. It's not breaking anything, but thoughts welcome as I'm out of time atm.

[Bill Sheboy]

First, the nested conditionals work because there is no scope reduction: both isInternal and author are still visible under comment iteration.  (This would be different if you tried to access the assignee from inside the comment iterator: it is "higher" in scope for the issue rather than the comments, and so not visible.)

Next, regarding the 100 item limit: that is in the REST API endpoint, which rules use to perform actions.

And, I believe when {{issue.comments}} is referenced, it already gets the most recently added (or edited) ones, up to 100 items.  And so I would remove the reverse, and validate that.

Then after the variable is built, just use this:

{{commentDates.split(",").toDate.max}}

If that does not work as expected, you may absolutely enforce the order by directly calling the REST API endpoint to Get Comments using the Send Web Request action, adding the orderBy parameter.  Then again filter by the internal state and email address to store in a variable.

However this time, if you get the comments in reverse order with the endpoint, the first one found in the variable will be what is needed.

[Oliver Moore]

Hi Bill,

thanks for this.

{{#issue.comments.reverse}}Reverse Date: {{created}}{{/}}

{{#issue.comments.reverse}}Date: {{created}}{{/}}

both give:

Reverse Date: 2025-07-22T13:56:28.2+0000
Reverse Date: 2025-07-22T13:38:13.2+0000
Reverse Date: 2025-07-22T13:31:03.5+0000
Reverse Date: 2025-07-22T13:28:41.3+0000

Date: 2025-07-22T13:56:28.2+0000
Date: 2025-07-22T13:38:13.2+0000
Date: 2025-07-22T13:31:03.5+0000
Date: 2025-07-22T13:28:41.3+0000

 So looks like reverse has no bearing here as you thought.

The max date function works great, other than it includes a timestamp which the edit issue doesn't like, so I am fixing that with a 2nd variable based on the max, and then taking the left 10 characters for the date only.

Thanks for the help - much appreciated!

Oliver

[Bill Sheboy]

Did you mean to use examples with and without the reverse?

Rather than using text functions, please try date formatting handle it:

{{commentDates.split(",").toDate.max.jiraDate}}

[Oliver Moore]

Bill - I clearly had too much/not enough coffee on the reverse comment. It does work as expected. (e.g. reverse gives you the newest comment first)

Thank you once again for the additional tips on the max date.

[Hannes Obweger - JXL for Jira]

Hi @Oliver Moore

I'm glad to see that you're able to progress on your Automation-based approach!

Just for future reference, if you're open to solutions from the Atlassian Marketplace, you may want to have a look at the app that my team and I are working on: JXL for Jira.

JXL is a full-fledged spreadsheet/table view for your issues that allows viewing, inline-editing, sorting, and filtering by all your issue fields, much like you’d do in e.g. Excel or Google Sheets. It also comes with a number of so-called smart columns that aren’t natively available, including the Time since last external comment (along with many other comment-related smart columns). 

This is how it looks in action: 

(I'm using the last internal comment columns here, but it would look the same for external comments.)

As you can see above, you can easily sort and filter by your smart column, and also use it across JXL's advanced features, such as support for (configurable) issue hierarchies, issue grouping by any issue field(s), sum-ups, or conditional formatting.

This all just works - there's no automation or scripting whatsoever required.

The one part of your rule that I didn't quite grasp just yet is where you check for the initiator. Happy to dig into this more if JXL could be an option for you!

Any questions just let me know,

Best,

Hannes