Hello Atlassian Community!
I want to create Automation which sends e-mail to certain user with all the comments from the work item added after the date saved in custom field.
I created date-time customfield_11982, which is currently Mar 08, 2026, 8:55 PM (2026-03-08T19:55:19.4+0000).
Five comments were added after this date and time but no comment is sent by e-mail.
My current smart values in automation looks like this:
{{#issue.comments.reverse}}
{{^author.displayName.equals("Automation for Jira")}}
{{#if(created.jiraDateTime.isAfter(issue.customfield_11982.jiraDateTime))}}
[{{author.displayName}} ({{author.emailAddress}}) - {{created.format("dd-MM-yyyy HH:mm")}}]:
{{body}}
-----------
{{/}}
{{/}}
It works properly when instead of "issue.customfield_11982.jiraDateTime" there is for example now.minusHours(4).
Hello @Dominik Kaźmierski
I think the problem is here: issue.customfield_11982.jiraDateTime
isAfter() compares date objects, but .jiraDateTime formats the value as text. That would also explain why now.minusHours(4) works, because that is still a real date value. Atlassian’s smart value docs show isAfter() being used directly with date fields, not with formatted text.
Hi !
Thank You for your answer.
Do You have any ideas how to compare those two values then?
I tried using created.gte(issue.customfield_11982), created.jiraDateTime.gte(issue.customfield_11982.jiraDateTime) and created.toDate.isAfter(issue.customfield_11982.toDate) - it doesn't work as well.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
yes, I would try it without .jiraDateTime.
So I would test:
{{#issue.comments.reverse}}
{{^author.displayName.equals("Automation for Jira")}}
{{#if(created.isAfter(issue.customfield_11982))}}
[{{author.displayName}} ({{author.emailAddress}}) - {{created.format("dd-MM-yyyy HH:mm")}}]:
{{body}}
-----------
{{/}}
{{/}}
{{/}}
If that still does not work, I would add a Log action first and print both values, just to verify the field is really available in the rule in date format.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi!
I tried {{#if(created.isAfter(issue.customfield_11982))}} already and it doesn't work.
I also added Log actions and it seems that fields are available as date formats:
But it seems not to work in "send e-mail action" while iterating through all the comments (deleted {{^author.displayName.equals("Automation for Jira")}} for now, just to be sure, that it doesn't interfere with the rest).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Please paste Screenshot from entire Automation.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
from what you shared, I think the issue is no longer the date field itself.
Your audit log seems to confirm that issue.customfield_11982 is available as a real date, and that comparisons like issue.comments.last.created.isAfter(issue.customfield_11982) can work.
So the more likely problem is the smart value context inside the Send email loop.
You are testing one thing in the log:
{{issue.comments.last.created.isAfter(issue.customfield_11982)}}
but in the email body you are iterating over all comments and evaluating:
{{#issue.comments.reverse}}
{{#if(created.isAfter(issue.customfield_11982))}}
...
{{/}}
{{/issue.comments.reverse}}
So at this point I would debug the iterator itself first with a very small test, for example:
{{#issue.comments.reverse}}
created={{created}}
cutoff={{issue.customfield_11982}}
test={{created.isAfter(issue.customfield_11982)}}
---
{{/issue.comments.reverse}}
If that renders values, then the loop works and the remaining issue is just the nested #if block or template structure.
Then I would try this simplified version:
{{#issue.comments.reverse}}
{{#if(created.isAfter(issue.customfield_11982))}}
[{{author.displayName}} - {{created.format("dd-MM-yyyy HH:mm")}}]
{{body}}
-----------
{{/}}
{{/issue.comments.reverse}}
So my guess would be the date comparison is probably already okay now, and the actual problem is more the scope / rendering inside the comment iteration in the Send email action.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Arkadiusz Wroblewski
Your suggestion was on point!
I tried debugging with:
{{#issue.comments.reverse}}
created={{created}}
cutoff={{issue.customfield_11982}}
test={{created.isAfter(issue.customfield_11982)}}
---
{{/issue.comments.reverse}}
I added some other custom fields with different types (date time, only date, text) and variables.
As it turns out loop is the problem! Every custom field and variable inside loop returned no value.
It seems that loop is very limited entity and it doesn't allow any custom field or variable to be used inside of it. Only system, global fields seem to be available. Hence {{now}} worked.
But at this point I have no idea, what can I do next.
I tried filtering outside the loop with: {{#issue.comments.reverse.created.isAfter(issue.customfield_11982)}}
but I couldn't make it work.
Do You have any suggestions how could I handle this problem?
Thank You!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
that is a very good finding.
If all custom fields / variables go empty inside the comment loop, then the issue is likely context/scope inside the iterator, not the date comparison itself.
One thing I would still test is using triggerIssue instead of issue inside the loop, for example:
{{#issue.comments.reverse}}
{{#if(created.isAfter(triggerIssue.customfield_11982))}}
[{{author.displayName}} - {{created.format("dd-MM-yyyy HH:mm")}}]
{{body}}
-----------
{{/}}
{{/issue.comments.reverse}}
The reason is that in changed execution contexts, issue may no longer point to the original issue the way you expect, while triggerIssue can still reference the source issue.
If triggerIssue.customfield_11982 is also empty inside that loop, then I would start treating this as a smart value limitation / bug in the email action rather than a syntax problem. Atlassian does document cases where smart values can become empty depending on context.
So my next step would be:
test triggerIssue.customfield_11982 inside the loop
if that also fails, consider a different rule design, for example trigger on comment added instead of trying to filter the full comment list in the email template
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Arkadiusz Wroblewski Hello!
Thank you for all the help.
I contacted Atlassian support regarding this topic and as it turns out it is impossible to call custom field values inside the loop and there is currently no workaround.
It seems the only way is to trigger automation on comment added - but unfortunately it is impossible in my case because it would use up rest of my monthly available automation uses.
Have a nice day!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @Dominik Kaźmierski
Glad Atlassian Provided you answer and im Sorry it can´t work now the way you need.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.