I have a pretty straight forward workflow for my JIRA Service Desk Incident type. A ticket comes in it's assigned to a Component group.(Assigned to Team) A member of the Component group assigns the ticket to themselves or a member of there group which transitions the ticket to "Assigned to Agent" and from there they go back and forth with the customer (Waiting for Customer and Assigned to Agent) until it is moved to resolved.
My question is during the Assign to Agent transition a screen comes up to assign the ticket. (See attached number 1) I would like an automation or maybe this is a workflow post function to transition the ticket to Waiting for customer if the agent puts a comment in that screen.
I am a full JIRA system admin using JIRA 7.5 and JIRA Service Desk 3.8.1
The problem here is that if you see this screen, this is already a transition screen. That means that it's possible this issue can change it's status when you complete this form. But it sounds like you might then also want it to change status again immediately to reply to the customer and set the issue to waiting on customer.
Since this is an assignment screen, I don't think this should be really be intended for use as a means to reply to the customer just yet. In most cases this comment field might be empty, or in some cases, I could see where a dispatcher is assigning the issue to another Agent and in turn just wants to leave an internal comment for that agent in regards to this case or some additional information that Agent should know.
It seems potentially problematic to write up a response to a customer in this view before the issue is actually assigned to the Agent intended to work that issue. The reason for that is, until the issue actually has an Assignee value, the rest of your JSD Agents don't know who is working that issue. Meaning that someone else might come along and start working that issue while you might be composing a response to the customer. So in order to try to help avoid duplication of support efforts, it feels like this page should only be used to quickly assign issues and then move on.
I agree with this but wondered if there was an automation that could look to see if a public comment was added and if yes transition the issue? Or if not is there any way to remove or hide the comment field? Understandably, the answer to both of these questions might be no just thought I would ask.
Thanks!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes there are automation rules that can be setup to transition on comment. And those rules can use configured to check if the comment is public. My concern with doing this is the other fields that this automation rule will check for, and the status of the issue at the time this comment is added. Since this is a transition, the status can change at the same time the comment is added. So if you use this automation rule you will likely need to have it set to trigger on the destination status. By default in my Jira 7.7.0 (with service desk 3.10.0), there is a automation rule called "Transition on Comment".
The other thing about this is that the automation rule is set to look for "Comment is primary action". In your case, I don't believe that the comment is the primary action here, instead this is another transition that is also assigning a user. So you might be able to tweak the automation rule as one way to handle this.
The alternative is to edit the screen in use for that request type's transition. While Jira won't let you remove the comment field from that transition screen, it might be possible to hide that field with a little bit of javascript hacking. There have been other users that have wanted to hide that specific comment field before, and it seems there are a few documented work-around that could be used. See https://community.atlassian.com/t5/Jira-Core-questions/Remove-Comment-text-box/qaq-p/140997 for more details. In cases like that, you can either add that script to the announcement banner for Jira, which would be site wide, OR in some cases users will add that script to custom field that is known to be appearing on that specific screen. This latter method provides a bit more granular control over which projects you can restrict this comment field appearing on.
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.