We're having problems isolating the last time a comment was added to a service desk ticket that was visible to the customer (i.e. when was the last time they heard from us versus all the internal comments).
I can't find any JQL functions that'll separate the "Internal" comments from the "public" ones, however i see that the Jira Service Desk (built-in) automations can distinguish between them just fine. I'd like to capture when those public comments are made and update a custom Date Field to show the current timestamp when that automation runs (so we can perform JQL searches against the value).
However, it appears that the built-in automation will ONLY accept a specifically formatted date value rather than "Now()" or "{{currentDate}}" or any kind of smart-value.
Is it possible to use a smart-value for custom Date fields in the Built-in Jira Service Desk automations?
My solution turned out to be two-fold:
1. using the built-in automations that are provided with Jira Service Desk: When an agent posts a comment that is public facing, the automation edits the ticket to have the label 'agentcomment'.
2. using the "Automation for Jira" add-on (which provides the ability to apply {NOW} as a timestamp, but doesn't know how to differentiate between Internal/External comments), I look for for tickets that have been edited to include the label 'agentcomment' and update the custom date field with {Now} and then remove the label 'agentcomment'.
It's a bit of a Rube Goldberg method (admittedly) but it appears to be working.
Hello Charles,
I believe to achieve what you are looking for you would need to have the automation rule trigger a transition and then on the workflow use something like what is described In this post or this post or this post to set the field value via a scripted post function during the issue transition. In the automation rule directly you can only edit some system fields and you cannot modify Custom fields so you would need to look into an add-on that can extend the behavior as describe in the previous posts linked above.
But, thinking on this one a bit, another option here that might simplify this wold be to use SLA rules to track time between replies of various workflow steps. And there are SLA specific JQL's and Reporting on SLAs you can use to find issues in various phases of the SLA and keep track of this metric over time.
In the SLA rules there are "Comment By Customer" and "Comment for customer" events that can be used to trigger the start and stop SLA metrics to track this.
Regards,
Earl
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.