It seems like a known issue but I see a few workarounds already shared by community members. I have tried using Automation but unable to achieve the desired results. here are some screenshots for reference;
Hi @AB
I think its a combination of the smart value and the rule.
@Trudy Claspill is right on the smart value, but triggering on linking and then add the linked issue requires a brand.
If you don't branch all actions are on the issue that is triggering the rule, not the linked issue.
Try: (adjust to your link requirement and naming)
Hi AB and Trudy,
The culprit of the automation is the left hand side of the equation: it should hold the name of the field (in this case being Team). The righthand side of the original equation of AB is right, there is no need to put .Id in the smartvalue.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
An acceptable alternative to using the field name is to use the custom field ID in the JSON code.
And it seems that the id attribute is required since using that eliminated the error received when it was not used.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @AB
Try using the value {{triggerIssue.fields.customfield_29790.id}}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @AB
Which issue did you expect to be updated?
The way the rule is written the issue that is triggering the rule is also the one that is getting updated, and it is being updated with the value that it already has in that same field. I don't think that is what you want.
Which is the issue that was split? Which is the issue that was generated by the split?
When you look at the issue that was split and look in the linked issues section what is the link text (i.e. "split from" or "split to") that is shown to describe the link to the newly created issue?
The Issue Linked trigger is a unique trigger because there are two issues involved in the process, but only one of those issues can be considered the issue that triggered the rule. Depending on the type of link used and what the relationship is to the other issue, the issue from which the link is created may not be the one that triggers the rule.
For a more detailed explanation refer to the answer that I posted on this Question:
I suspect that the issue being split in your scenario is the one that is triggering the rule, and subsequently the one that the rule is trying to update.
To solve the problem you need to add a branch to change the focus to the issue created by the split. You can use the branch For: Related Issues: Destination Issue, and then nest the Edit action within the branch, as I have shown in my answer on the other post.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.