How to iterate over a created variable

[Dave F]

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.

[Bill Sheboy · Accepted solution]

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:

{{assigneeList.split(",")}}

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

Kind regards,
Bill

[Dave F]

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]

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

To try and understand what's happening better I:

1. Created a var called counterA set to 0 before the Advanced Branching step.
2. 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)"
3. 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)

[Bill Sheboy]

If I understand the technique you tried...Incrementing a loop counter inside of a branch (which could process more than one issue) does not work in a predictable manner. 

Such branches split off to execute independently and asynchronously, and so the variable is created new for each pass of the loop.  The only branches which do not do this are the one-and-only-one issue branches, such as Current Issue and Epic Parent, as those get converted into in-line code behind the scenes.

Would you please post an image of your complete rule?  Seeing that may reveal some context for other possible causes for this symptom.  Thanks!

[Dave F]

Ah, so branching is more like multithreading than a loop. Thanks.  That said, the countA variable did increment for each assignee.

Here's the automation as it stands now.

The assigneeList variable is set to {{lookupIssues.assignee.accountId.distinct}}. I think everything else is in the screenshot.

The body of the email is:

Hi {{anAssignee.displayName.split(" ").first.capitalize()}},

Remove these once this automation works correctly:
. {{anAssignee.emailAddress}}
. {{anAssignee}}
. {{lookupIssues.key}}

You currently have {{lookupIssues.key.size}} Patch requests in a status that suggests the work for them is not Done. These are due soon, or are overdue.

[Bill Sheboy]

Does your trigger have any JQL, as that could cause duplication?

And as you are referencing other assignee fields in the email (e.g. displayName) I do not think you can just use the accountId to drive the loop/advanced branch.

I just tried this rule logic like yours and it worked for me:

• trigger: scheduled with no JQL
• action: lookup issues with JQL to find issues, including ones with multiple issues per assignee
• advanced branch on: {{lookupIssues.assignee.distinct}} and a variable of {{varAssignee}}
  • action: log just the {{varAssignee.displayName}}

This logs one entry per assignee found.

So perhaps try that first to confirm your rule scaffolding, and then add the second lookup issues inside the loop, then finally add the email.

[Dave F]

It looks as though JQL is indeed the culprit. I now have a rule that only sends the 2 emails, which seems counter-intuitive to have a trigger that grabs all the issues and results is less emails.

Thanks @Bill Sheboy 

[Bill Sheboy]

Excellent!  I am glad that was it, as I was running out of suggestions.  :^)