Automation to update subtask summary after automatic creation of subtasks

[Michail Kotantakis]

Hello team

I have a rule that when the value of the approvers changes, it creates as many subtasks as the approvers in the list and assigns also each subtask to each approver as shown in the screenshot below: This works fine and as expected.

After this i branch the rule for each subtask and i edit the summary of the subtask to show the assignee name of the subtask with additional text .

It works only if i have one approver. if i have 2 approvers it executes first this branch and then the For each with a consequence that the assignee name is not passed to the subtasks

Could you help on this please? Any ideas?

Thanks

[Bill Sheboy · Accepted solution]

Hi @Michail Kotantakis 

Please post an image showing the details of your advanced branch, showing the smart value expression to set the {{ApproversList}} variable.  That may provide some context for why the iteration is not working for multiple approvers.

Until that is posted, I see another problem with the rule...

Branches on one-and-only-one issue (e.g., branch on Current Issue, Parent (Epic), etc.) run in-line, as if there was no branch.  And so the rule steps occur in the order you write them.

However...branches which could be on more than one issue (e.g., advanced branches, JQL, for sub-tasks, etc.) are run in parallel and asynchronously.  There is no guarantee of when the branch will finish, up to the ending point of the rule.

For your rule, the first branch may not finish before the second one runs.  For your use case, the two possible work-arounds/solutions are:

1. Edit the summary at the same time you create the sub-task.  This is probably the better approach as it will do all of the actions in one step.
2. Create a second rule, triggered on issue create, and detect that a new sub-task needs the summary updated.  This approach could run into other challenges as you would need to detect when *not* to add the assignee information to the summary.

Kind regards,
Bill

[Michail Kotantakis]

Hi @[deleted].

Thanks for looking into this.

This is how the smart value is written: {{issue.Approvers.accountId}} and I use the ApproversList variable so then in the create subtask to create as many as the approvers and assign each subtask to each approver. Till that point it works fine.

If I try as per your suggestion to edit the summary of the subtask with the assignee at this step too, which I tried, with two options I get the following: if I use the smart value with the Variable {{ApproversList}} in the summary it works but prints the account id.

If I use in the summary {{assignee.displayName}} I do not get anything, same if I use{{issue.assignee.displayName}}}.

In regards to your other suggestion for detecting the subtask I tried with an extra rule but I am unable to make it work for subtasks

Any ideas?

[Michail Kotantakis]

Hi @Bill Sheboy 

Here is also the screenshot of the variable and the smart value, and below that is the subtask creation

If i put into the summary the variable smartvalue {{ApproversList}} it will add a single approver in every subtask but with the account id, as this has been declared in the variable creation since the assignee works with the account id as from what i have read

What i did is that i added another variable to get the display name of the approvers and then edit the summary with this variable, but in this case it adds the names of all the approvers in each subtask. What am i missing here 

[Bill Sheboy]

Thanks for that information!  Let's try this...

• Use the entire Approvers field in the advanced branch smart value {{issue.Approvers}} as that will provide the entire user object to the branch iterations (as described in this article)
• Then in your sub-task create you may reference the variable's fields, as needed:
  • {{ApproverList.accountId}}
  • {{ApproverList.displayName}}

One more tip: I recommend naming branch and created variables so they are clearly different from built-in smart values.  For example, varApprover.  That avoids the potential of accidentally colliding on smart value names.

[Michail Kotantakis]

@Bill Sheboy 

Just tested and worked like a charm!!!!!!!!!!!!!!!!!!!!!!!

Thanks a million for this.

It totally went off of mind that using the whole object gives you the possibility to adjust your smart value later by adding specific attributes then

Thank you very much for this and for the tip for the naming tip.

Kind regards

[Bill Sheboy]

Awesome!  I am glad to learn that helped.

Please consider marking this question as "answered"; that will help others in the community find solutions to similar questions faster.  Thanks!