Having Trouble Looping by Assignee in Jira Automation — Can’t Get Names or Tasks to Line Up

[Brendan Connelly]

Hi everyone,

I'm building a Jira Cloud Automation rule to send daily reminder emails for issues that are missing due dates. The goal is to send just one email per assignee, listing all their missing-due-date tasks — instead of spamming them with multiple emails for each issue.

However, I’ve run into critical issues that are preventing this from working at all. 

Specifically:

I can’t reliably isolate the correct displayName for each assignee within the loop.

I can’t generate a task list that includes only that assignee’s issues — the filtering fails or leaks issues from other users.

So far, none of the core logic is working correctly.

---

Rule Logic Overview:

1. Scheduled Trigger:

Runs every weekday at 8:30 AM.

2. Lookup Issues (JQL):

status in ("TO DO", "IN PROGRESS") AND dueDate is EMPTY

3. Advanced Branch:

Loops over:

{{lookupIssues.assignee.accountId.distinct}}

with "assigneeId" as the branch variable name.

4. Inside Each Branch Iteration:

I try to extract the display name for the current assigneeId

I try to filter and list only the issues belonging to that assigneeId

I send an email using those values

---

The Problems:

1. Getting the display name doesn't work.

Using:

{{#lookupIssues}}{{#if(equals(assignee.accountId, assigneeId))}}{{assignee.displayName}}{{/if}}{{/lookupIssues}}

Fails when used in Create variable — nothing returns or it throws a parsing error.

Also tried:

{{lookupIssues.match("assignee.accountId", assigneeId).first.assignee.displayName}}

But this always returns blank when assigned to a variable, even though assigneeId is valid in logs.

---

2. Filtering the task list by assignee also fails.

The goal is to produce a list like:

- KEY-123: Summary

- KEY-456: Summary

But looping through lookupIssues and trying to match assignee.accountId == assigneeId in an inline expression or template block either:

- Returns no issues

Or 

- Incorrectly shows tasks from multiple users

---

Confirmed Constraints:

Create variable only supports inline or single {{#}}...{{/}} blocks

Nested blocks like {{#}}{{#}}...{{/}}{{/}} throw template parse errors

match() and first() don’t reliably work when accessing nested fields in variables

---

What I Need to Do:

Each assignee should receive only one email, with:

Hello [displayName],

Here are your issues missing due dates:

- KEY-123: Summary

- KEY-456: Summary

[No cross-user data leakage, no repetition, no noise.]

---

Looking For:

A reliable way to extract a single displayName inside the assigneeId loop

A smart-value pattern that filters issues cleanly per assignee

Any proven workaround that avoids using nested smart value blocks

A way to get this working without using external scripts or multiple automation rules

Thanks for reading — and I’d really appreciate any working examples or creative strategies others have used to solve this.

[Bill Sheboy · Accepted solution]

Hi @Brendan Connelly -- Welcome to the Atlassian Community!

Short answer: once inside of an iterator, no outside data is visible (such as the branch variable), and so the rule compares an unknown / null value, causing the equals function to fail. 

To fix this, let's correct a couple of things:

You are essentially doing a variation of the scenario from this knowledgebase article:

https://support.atlassian.com/jira/kb/automation-to-send-a-single-email-to-assignee-when-multiple-issues-are-due/

However your rule (and that knowledgebase article) make a mistake: your branch variable is the same name as a built-in smart value (or function for the KB case).  That can cause the rule to get confused in parsing.  I recommend always naming variables in a way less likely to collide with other values, such as adding a prefix like: varAssignee.

And even if the name was unique, we have the scoping problem where a long-format iterator cannot see outside data.

The simplest way to fix both of these for this scenario is to repeat the Lookup Issues action inside of the branch, adding the branch variable to the JQL.  This is the technique used by that KB article.

• trigger: scheduled, with no JQL
• action: lookup issues with JQL to find any work items
• smart values condition: to check if any results were found
• advanced branch: over the distinct assignees from the lookup
  • action: lookup issues with JQL to find the work items for the branched-to assignee
  • action: send the email
    • In this case, no list filtering is required as there is only one assignee at this point

A more complicated solution uses dynamic list searching with regular expressions, although that seems more than what is need here.

Kind regards,
Bill

[Brian Kirwa]

What’s worked well for me is branching over {{lookupIssues.assignee.accountId.distinct}} using a safer variable name like varAssigneeId, then running a second "Lookup Issues" action inside the branch with this JQL:

status in ("TO DO", "IN PROGRESS") AND dueDate is EMPTY AND assignee.accountId = "{{varAssigneeId}}"

That reliably filters each assignee’s issues without needing tricky inline filtering.

For the task list in the email, I use:

`{{#lookupIssues}}

• {{key}}: {{summary}}
  {{/lookupIssues}}`

And for the greeting line, since all issues belong to the same assignee at this point:

{{lookupIssues.first.assignee.displayName}}

Clean and effective — no need for nested blocks or additional rules. This pattern’s worked well for me in similar daily digest automations.