Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Using automation to prevent reopening when a customer comments "Thank You"

The Current Regular Expression:

\A(\{.*\}\n?\s?|<.{0,5}>|[_+*\-])*[Tt][Hh][AaxX][Nn]?[Kk]?s? ?[Yy]?[Oo]?[Uu]?[^%]*$


I know we're not the only ones who deal with this. We resolve the issue, put it into "Resolved", and the customer replies "THANKS!" or some other variation, triggering the issue to reopen. Then we have to manually close it again.


I've worked out more of the details in this thread with community assistance, and further poking and prodding at the commenting system has allow more adjustment of the regular expression that fuels this.


Here's the rough overview of how the rule is assembled in my environment:

Screen Shot 2022-04-19 at 10.11.19 AM.png


The "Compare two values" is the lynchpin of this. The intent of this automation is:

  1. Determine if the comment starts with some known predictable form of "thank you"
  2. Ignore this gratitude form if it ISN'T at the start of the comment.

There are some chances for sweeping up false positives. The following messages would ALSO be ignored:

  1. Thank You! Can You also fix ...
  2. Thanks for nothing!

These have been deemed acceptable in our environment, but that's a consideration each org would have to make themselves.

Reasons behind the design of the regular expression:

Testing more simplified versions of the regex pattern revealed hit-and-miss results. Having the automation kick the {{comment.body}} out to  a webhook showed that {color:#000000} was preceding the text. Some searching revealed this document, which highlights some of the many potential patterns and characters that can precede a comment when it is being evaluated by automation. These were the cause, and adjusting the regex to account for them resulted in a MUCH higher hit rate.

The regular expression attempts to account for `{color:whatever}` and some common markdown text formatters (italics, bold, strikethrough). The regex does NOT account for ALL of them, but it suits my needs for now. You may choose to further adjust to your local needs.

1 comment

This is definitely helpful and I will be testing this out - looking forward to what others can contribute. Ill circle back with any changes I might have!

Like jshippy likes this


Log in or Sign up to comment

Atlassian Community Events