"On Hold" status unassigns agent from issue

[Deleted user]

When responding to a customer, the issue changes to "On Hold" status. The issue then subsequently unassigns the agent that is assigned to the issue. 

I'm not sure as to why this happening, and I was hoping someone might have an idea as to why?

Thank you

[Tessa Tuteleers]

Hi Robert, 

this is probably a post function in the workflow, when the issue is put on hold.

Most probably so that, when the customer responds and the issue comes back to support, any team member can pick it up and continue work on the issue so the customer gets the fastest response.

It is of course possible to  change this behaviour. E.g. if you want 1 agent to work the ticket from start to end you can keep it assigned. 
You will have to ask your JIRA administrator to edit the workflow and remove the "clear assignee" post function from it. 

Hope this helps 

- Tessa

[Deleted user]

Hi Tessa, 

Thanks for your response. I was unable to find a "clear assignee" post function on the workflow. I have, however, added an "Assign to current user" post function, which will ensure it won't be unassigned. 

Thanks for your help.

[Tessa Tuteleers]

Hi Robert, 

this is a nice solution to auto assign an issue to the user initiating the transition, however it is not a an answer to your problem. 

Why? 

1. Your solution will make the assignee of the issue change. It won't keep the original assignee unassigned.
2. You don't address the unassigning method. In the backend the "unassign issue" command will still run somewhere and could break your flow. 

Should the user re-opening the issue also be the person that has to be assigned, your solution would be ideal (if you also find the unassigning engine and stop it), most probably that won't always be the case.  (e.g. a customer re-opens the ticket, you probably want the original agent to stay assignee) 

How can you find the "clear assignee"? 

• In the workflow: sometimes it is added to the workflow as a postfunction and it could look something like this: 

However, If there's nothing like that there, it could be configured differently with an app on your instance. 

• Another major possibility in JIRA Service Desk is the automation engine, making up the rules for behaviour in issues, which probably also tells the issue to change status when a comment is placed. If you can find it there, just edit the rule to no longer unassign the issue on transition

Hope this helps!! 

[Tessa Tuteleers]

Hi Robert, 

this is a nice solution to auto assign an issue to the user initiating the transition, however it is not a an answer to your problem. 

Why? 

1. Your solution will make the assignee of the issue change. It won't keep the original assignee unassigned.
2. You don't address the unassigning method. In the backend the "unassign issue" command will still run somewhere and could break your flow. 

Should the user re-opening the issue also be the person that has to be assigned, your solution would be ideal (if you also find the unassigning engine and stop it), most probably that won't always be the case.  (e.g. a customer re-opens the ticket, you probably want the original agent to stay assignee) 

How can you find the "clear assignee"? 

• In the workflow: sometimes it is added to the workflow as a postfunction and it could look something like this: 

However, If there's nothing like that there, it could be configured differently with an app on your instance. 

• Another major possibility in JIRA Service Desk is the automation engine, making up the rules for behaviour in issues, which probably also tells the issue to change status when a comment is placed. If you can find it there, just edit the rule to no longer unassign the issue on transition

Hope this helps!! 

[Deleted user]

Hi Tessa, 

Thank you for that very comprehensive response. 

Having taken your approach, I have managed to resolve your the issue I was having. 

Thanks again!