Automation logs don't match expected output

[Jordan Dowdy]

I am building an automation rule that is configured the following way:

1. There is a custom field [current team composition] in a project that is a multi-user picker and populated by another automation which queries the project role API and only adds users in the 'team member' project role. 

2. The new rule I'm working on first does a lookup in a specified project and returns issues that were resolved in the last 12 weeks only. I use the smart value {{lookupIssues.assignee.displayName.distinct}} to get the assignees of those issues. 

3. I save this smart value as a new variable which transforms it from an array to a string from my understanding and research. 

4. Then I do another lookup which queries the custom field mentioned in point 1. and returns {{lookupIssues.customfield_xxxxx.displayName}}

5. I then iterate on this with a branch to compare each user against the string variable (The string variable should have less users than the custom user picker field)

6. In the branch I check if the current iterated user (which should be a display name string) is not found in the variable string. If the user is not found in the string it should log them.

• The condition is: If variable (string) does not contain {{branch iteration}}<- (user display name string), then log the user 

7. Unfortunately, it is logging every user that is iterated.

• In the scenario that I'm running the JQL lookup for active users in the last 12 weeks returns 10 users
• The user picker field has 12 users
• The condition should only pass for 2 of the users
• In other words, the condition is failing to pick out name strings from the string variable and therefore logging every user iterated in the branch

I have done checks like this before, checking a large list or string block to see if it contains something specific and have had no troubles in the past. Does anyone see error in the logic, or have a solution to fix this?

[Bill Sheboy · Accepted solution]

Hi @Jordan Dowdy 

Even with your description of the steps, perhaps more context will help. Please post the following:

• what type of project is this: company-managed, team-managed, JPD, etc.
• an image of your complete automation rule in a single image for continuity
• images of any relevant actions / conditions / branches
• an image of the audit log details showing the rule execution

Until we see those...

You describe using advanced branching over the values to perform the comparisons. Branches which could be over more than one thing are processed in parallel and asynchronously. Thus I wonder if there is either a scoping or timing problem for what you describe. Seeing the details may help confirm it.

Another approach to compare the matching (or different) values between two lists may be done with regular expressions. Please see this article for more information:

https://community.atlassian.com/forums/Automation-articles/Automation-concepts-Find-Overlaps-Between-Lists/ba-p/3045704

And please note: as you are storing your assignees' displayName values in variables (which are text), those variables would need to be split() back into lists to use the technique in the article.

Kind regards,
Bill

[Jordan Dowdy]

Hey Bill, this is a company managed project. I know about the branches running async but each branch should be comparing one user's display name against a single string variable containing all the team's users so timing shouldn't be an issue here. Especially because the full list of users is consistently logged when only two of them should be. Attaching the rule details as well. 

[Bill Sheboy]

Ah, a lists of lists problem!

Short answer for the fix is change the branch's smart value expression to use flatten and distinct.

{{lookupIssues.customfield_11610.displayName.flatten.distinct}}

More information...

Inside the lookup results, each work item has a list of values in the multiple-selection, user field.  When that gets parsed as you show, the iterator values are sets of selections by work item. 

For example, if the lookup results had:

• Work item TEST-123, custom field value A, B, C
• Work item TEST-456, custom field value A, B, E
• Work item TEST-789, custom field value F, G, B

All three sets would be provided as iteration values, and likely not matching the activeTeam as a set, and so would pass the condition operation on "does not contain".

[Jordan Dowdy]

The lookup issues is only returning one issue by key, and if the iteration value was the set of work items, that would be reflected in the log action where each of the 12 users is being logged. That's why it doesn't make sense because the active team variable clearly logs all the users, and each iteration value is an individual user that corresponds to every user in the active team variable as it is logged too. 

[Bill Sheboy]

Even when the lookup returns one issue, that still produces a list-of-lists.  One way to confirm that for your rule is inside the branch, write this to the log as the first step:

teamComp: >>{{teamComp}}<<

If the values are iterated as individual displayName values, each one will have that prefix and be surrounded by those >> and << characters.

[Jordan Dowdy]

Ah that makes sense, and I can confirm that .flatten works. Thanks @Bill Sheboy !