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:
The "Compare two values" is the lynchpin of this. The intent of this automation is:
- Determine if the comment starts with some known predictable form of "thank you"
- 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:
- Thank You! Can You also fix ...
- 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.
4 comments
