nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to iterate over a created variable

Dave F_0wxonz

We have a project where sub-tasks are automatically created every month and many of them are automatically assigned with a due date. I've recreated this project for testing this automation and I have about 11 sub-tasks (total) assigned across 2 assignees.

I'd like to create an automation that summarises (just a count) the outstanding tasks for each assignee. In future, hundreds of sub-tasks will be created each month, and I want to provide a link to a Kanban board in the email, not the individual sub-tasks to promote using the board as the preferred behaviour, so a filter subscription isn't appropriate.

Step 1, I use a Lookup Issues to list all the outstanding assigned tasks.

Advanced Branching seems to be creating a small list of assignees (hard to tell when Log Actions seems to reduce duplication). The branch creates a variable called anAssignee with from {{lookupIssues.assignee.distinct}}

Inside the branch I have a Lookup Issues that I want to use in the email to should an assigned issue count for the assignee. That seems to work (again, testing with logging).

The problem comes when it gets to the email step. I'm expecting 2 emails, however dozens of emails are sent to the 2 distinct assignees - more emails per assignee than they have assigned sub-tasks.

My automation looks like this. Any help towards getting a single email per assignee with an sub-task count is appreciated.

Jira Automation List trouble.png

Accepted answers

Bill Sheboy

Hi @Dave F

First, given the potential for spamming, I recommend modifying your data or initial JQL (or use a test project with less data) to carefully set up your testing conditions for this type of rule. That will help you limit the emails to precisely understand what is happening during testing.

Next, what are you able to observe as the relationship between the number (and assignee) to whom the emails are sent, relative to the data?

Another next...what does the smart value for your branch look like?

The source appears to be a Created Variable, and I believe those are currently still text (string) values...for yours rule, I would expect the variable to contain a CSV list of distinct assignees found from the first Lookup Issues action. So...I would expect your branch smart value to be:

Or...are you observing the {{assigneeList}} to actually contain objects, not just the accountId values?

Kind regards,
Bill

All comments

Bill Sheboy

Hi @Dave F

Next, what are you able to observe as the relationship between the number (and assignee) to whom the emails are sent, relative to the data?

Another next...what does the smart value for your branch look like?

Or...are you observing the {{assigneeList}} to actually contain objects, not just the accountId values?

Kind regards,
Bill

Dave F_0wxonz

Hi and thanks again for offering help, Bill.

First, I have my test address hard coded as the email address for now. Once I'm happy with how it works I'll change it to {{anAssignee.emailAddress}}

Smart Branching is set to use {{lookupIssues.assignee.distinct}} and store it in a variable called anAssignee. I had hoped the Distinct would make the branch run fewer times, but no such luck (or I'm using it wrong).

The Audit Log action in that 2nd last step gives me "Thomas S (9), Dave F (1)"

using the .split as you suggest in another log action just shows me the two user IDs as expected.

The automation produces 22 emails:

11 for Dave (me), all with the subject "You have 1 open Patching tasks..."
11 for Thomas, all with the subject "You have 9 open Patching tasks..."

The count of tasks is correct: Dave 1, and Thomas 9.

I suspect the created variable and the branch variable are objects and not just the user ID as a string because I can use other list options such as {{asAssignee.displayName}}

I put these in the email to try and diagnose what's going on:

{{anAssignee}} - gave me the assignee ID
{{anAssignee.index}} - nothing
{{anAssignee.split(",")}} - nothing
{{lookupIssues.key}} - game me a list of the tasks that user had assigned (1 for Dave, 9 for Thomas)

Strangely enough, logging {{assigneeList.split(",")}} before the branch gives me 2 the two user IDs, but logging {{anAssignee.split(",")}} inside the branch gives me nothing.

So I'm none the wiser as to why I'm getting so many emails. It's like the last Lookup is also looping within the Branch loop

Bill Sheboy

That last part makes sense to me: my understanding is advanced branching preserves an object (i.e. all fields of the user) while created variables are just text (i.e. and so defaulting to just accountId). The curious part is that the second distinct in the advanced branch appears to be getting confused/corrupted when spun off into the parallel processing.

How about trying this approach, so no lookup data is directly being used for the branch:

Let's assume you only need the accountId within the branch. Then you could change the created variable {{assigneeList}} to:
- {{lookupIssues.assignee.accountId.distinct}}
And change the smart value for the advanced branch to:
- {{assigneeList.split(",")}}

That should ensure you only have 2 loops for the branching, and let the internal lookup issues call do the rest.

Dave F_0wxonz

I tried that and got the same outcome, I'm sorry to say.

To try and understand what's happening better I:

Created a var called counterA set to 0 before the Advanced Branching step.
Inside Advanced Branching I set the var to "{{#=}}{{counterA}}+1{{/}}" before the lookup and added logging to record "Loop {{counterA}} {{anAssignee}} ({{lookupIssues.key.size}} tix)"
Put the same log line after the lookup and the result was the same

The log line suggests the loop is only running twice, so I'm confused as to how I'm getting so many emails. Log line:

Loop 1 6188665ef1ff560069a3418f (9 tix), Loop 2 610743796251c5006acc9cfd (1 tix)