Automation error when editing comment visibility

[Donald Duck]

I have an automation rule that runs when an issue transitions to Done.

Rule structure:

• Trigger: Work item transitioned → Done

• Advanced branching:

  • Variable name: comment

  • Smart value: {{issue.comments}}

• Action: Edit comment

  • Comment ID: {{comment.id}}

  • Set Comment Visibility to: Administrator (Role)

I started seeing errors in the audit log:

Unable to edit comment on work item
Visibility of this comment is set from the parent comment.

Functionally, everything still works:

• Parent comments are successfully updated

• Reply (child) comments correctly inherit the visibility from the parent

• All comments end up restricted as expected

However, the rule attempts to edit reply comments individually, which triggers the error because reply visibility cannot be edited independently it is inherited from the parent comment.

Is there a supported method to process only parent comments in automation?

[Marc -Devoteam-]

Hi @Donald Duck 

Try using {{issue.parent.comments}}

[Bill Sheboy]

Hi @Donald Duck 

Yes, and...to the suggestions from @Marc -Devoteam- 

In your advanced branch, you named the variable comment, which is the same as an existing smart value for work items.  Doing that can cause confusion for both people and the rule engine for what is intended in the rule.

I recommend always adding a prefix to variable names to prevent possible collisions, such as with varComment.

Kind regard,
Bill

[Donald Duck]

Hi  @Marc -Devoteam-  and  @Bill Sheboy  Thanks for the variable naming tip - I’ll rename it to varComment.

Regarding {{issue.parent.comments}}, my understanding is that this returns comments from the parent issue in the hierarchy, not from the current issue.

I tried using {{issue.parent.comments}} in the Advanced branch, but I received the error:

"The provided smart value couldn't be resolved to an object"

The rule works functionally as expected, but it started throwing errors once reply comments were introduced. Would appreciate any suggestions on the cleanest way to handle this.

[Bill Sheboy]

Would you please describe what your rule is trying to accomplish?  That is, "why do this?"  That context may help the community provide better suggestions.  Thanks!

[Donald Duck]

@Bill Sheboy 

Sure - happy to provide more context. The goal of this rule is to automatically restrict comment visibility once an issue is completed. In my flow, comments may contain internal or sensitive information that should not remain visible to all users after the issue is transitioned to Done. So when the issue moves to Done, the rule updates all existing comments and sets their visibility to a specific role 'Administrators'. This ensures that historical discussions remain accessible only to the appropriate group. Functionally the rule works as expected - it’s just the introduction of reply comments that started causing audit log errors.

[Bill Sheboy]

Thanks for that information, and...this may not be possible with an automation rule due to built-in limitations.

Your rule is close to what is needed, and could be simplified to:

• trigger: work item transitioned to Done
• advanced branch:
  • smart value: {{issue.comments.id}}
  • variable: varCommentId
    • action: edit comment
      • use {{varCommentId}} and set the visibility

However, branches have processing limits and I recall the maximum number of comments returned for a work item in a rule is 100 comments.  Thus, if you have more than 100 comments a single rule cannot update the visibility of all of them.  (A complicated and risky, multiple rule with recursion approach could handle more than 100 comments per work item.)

Regardless, if there are a lot of comments, the rule could encounter other service limits  (e.g., processing time) and halt the run of this rule, and possibly all other rules, for a period of time.