When a New ticket is assigned to an agent, the ticket status automatically changes to Open. You'll see the change after you update the ticket.
If you’ve activated ticket statuses: The ticket status will automatically change to your default ticket status in the Open category.
Once a ticket's status has been changed from New, it can never be set back to New.
If a ticket's status is set to Pending, Solved, or On-hold, and an end-user comments on the ticket, the ticket status will be set to Open.
If you've activated ticket statuses: If a ticket’s status is set to a status in the Pending, Solved, or On-hold status categories, and an end user comments on the ticket, the ticket status is set to your default ticket status in the Open category.
A ticket's status cannot be set to Solved by an end user or agent without an assignee. If an agent submits a ticket as Solved and there is no assignee, the system automatically makes the agent who solved the ticket the assignee.
Ticket type field values are not editable.
Once you set a priority, you cannot reset it back to no priority. You can always change it to a different priority.
When a ticket's status has been set to Closed, it can never be updated, it can only be deleted. Instead, the requester can create a follow-up request that references the closed ticket.
Once a ticket has been assigned to a group, an admin can reset it to no group by creating a trigger or automation setting the group value to null.
If there's only one group, all tickets are automatically assigned to that group.
If there is only one agent in a group that can be assigned tickets, all tickets assigned to that group will automatically be assigned to that one agent. Some agents in groups, such as light agents, do not have permission to be assigned tickets.
If there's only one agent in an account, then all tickets are automatically assigned to that agent and the agent's default group.
If an agent is only allowed to view tickets within their groups, and then they forward an email to Support, a new ticket is created and automatically assigned to the agent's default group. For information about how your account's default group and an agent's default group affect ticket assignment, see Changing the default group for your account or an agent.
You cannot assign a ticket to an agent without first assigning it to a group.
If an agent takes or automatically solves a ticket without assigning it to a group in the process, the ticket is assigned to the agent's default group.
Tickets are automatically closed 28 days after they're set to Solved, regardless of any triggers or automations.
The requestor field is mandatory. By default, Zendesk populates it with the person who created the ticket. If your agents are creating tickets on behalf of end users, and the agent forgets to add a requestor, the agent becomes the requestor.
If CCs and followers are enabled and an agent replies to a ticket notification they are no longer the requester or assignee for, they are automatically added as a follower to that ticket.
About native system ticket rules
Some business rules in Zendesk Support are native, meaning that they cannot be reconfigured and are default behavior in Zendesk Support:
The "When a ticket's status has been set to Closed, it can never be updated, " rule is causing us a lot of pain. It is impossible to organize old tickets in any way. The Product Management team cannot use Zendesk to find and mark user pain points. And just today we spent half a day investigating an issue that was a recurrence at a client - but the old ticket wasn't added to the organization when it was open, so it didn't pop up.
I understand why reopening the ticket is not possible, and I'm fine with followups. But not being able to add a single tag or field value to a ticket, or link it to another one, or to Jira - that I find incomprehensible.
The Requester field appears when the ticket created, but once the ticket has been submitted, the requester field will disappear. How can I make it appear again since the agent needs to change the requester?
Hi Suhan Li,
It's not intuitive at first, but it's right here under the title. We use this a lot for phone calls from shared numbers where we can't save the number to a particular user:
That is very helpful!
Only if this option is set in the Admin > Tickets settings.
With the new agent workspace, the mentioned "change" link won't be there, BUT the requester field will be shown at all times.
When I add an internal note in a ticket that already has the status "Pending" or "Solved", and click just the same status as I don't want the ticket to be reopened, it changes the status to "Open" automatically. I recall that before it was possible to update the ticket and the applied status was not changed to "Open". Has it been changed recently? Is there any way to make the status preserve when you update the ticket with an internal note?
Can you double check the events of the ticket to see if there's a trigger that keeps setting the status back to open? You should still be able submit the ticket in the same status it's already in without it re-opening.
Let me know!
I've read all of these threads pretty thoroughly and I have not found a solid justification for why it is impossible to re-open a ticket. My hunch is that it has something to do with how closed tickets are stored. E.g. archived as read-only in the database, to consume fewer resources.
I understand there are practical concerns to running gigantic databases and to changing low-level code. I would appreciate a candid answer on why people have been asking for this for *years* and there's no movement. I like a lot of things about Zendesk, but this is a dealbreaker for me.
Scott, speaking as a 9-year ZD user (overall a very satisfied one!) I think I recall seeing a comment to this effect from ZD staff a number of years ago. And it seems like a more than reasonable explanation to me.
Consistent with this -- I went to look for a several-year-old ticket yesterday, and was struck by how much longer it took to open than for more recent tickets. Seemed like it was being retrieved from somewhere different.
Thanks. If archiving to preserve resources is the reason, it should still be possible to have tickets stay writable for a cost. If a customer wants to pay a premium to keep all tickets in that state, it should be their perogative to do so, even if it's not a wise way to spend money.
A more cost effective option might be to temporarily pull large blocks of archived tickets back into an active state for housekeeping purposes.
Most of the reasons I have seen for needing edit tickets are a result of (A) implementing organizational ideas that were not thought of at launch and (B) lack of verification stage to correct problems in tickets before they get locked down, and (C) using tickets as a knowledge base and realizing that they contain incorrect solutions.
C is easy. Stop using tickets as a knowledge base.
B is mostly on the heads of management at the client site but perhaps Zendesk should work a bit harder to hammer the importance of ensuring agents consistenly follow certain rigid rules.
A, however, is normal and understandable; especially in organizations that use the Agile methodology.
The current option to correct these problems is to move to a different ticketing system. That's not good for anybody except Zendesk's competition. I work in process improvement and would honestly like to be able to recommend Zendesk. I like so much about the product, but this is a critical issue.
Seems like a fair analysis of the reasons.
As everywhere, there are so many more reasonable and technically doable enhancements than can actually be implemented -- and triaging them is always painful.
I'm having the exact same problem as Production.Zen. I have a admin account and I can't update a field value of a Closed ticket that is extremely important for us to set an analisis. Really find this incomprehensible too.
The official feature request to change the functionality to allow editing of closed tickets can be found in the community here:
Feature Request - Ability to edit closed tickets
The product manager recently updated the thread and indicated that it's under evaluation for the roadmap in 2022. I encourage you to add your comments and up vote the request, and that is where the product manager will continue to provide updates.
I can't find this answer anywhere!
For a Task, when you have a due date set, what is the default behavior / functionality of that field if you do not create an automation to accompany it? Would it send a reminder email when due? If it were On-Hold, would it switch to Open? Would there be some visual indicator on the List View?
Aside from what happens in Automations, the task Due Date can be used as a criteria in Views: see "Hours since..." here: Creating views to manage ticket workflow
I can't figure out the logic as to why we would want tickets to automatically be set to Open when they are assigned to agents. "Open" indicates that someone is working on the request. We have groups where there is only 1 agent active in that group. We have 8 US territories. Each territory has an assigned sales assistant. That sales assistant is the only agent who works the tickets that come into their territory group. That doesn't mean that the minute the email comes into the group and is assigned to that agent, it's being worked on. It's skewing our metrics for average time to complete.
Is there any option to forbid the end user to change the status for Solved?
As long as the ticket is not yet closed, the reply from the customer will reopen the ticket if they do it using the same thread. It's one of the inborn system ticket rules. You may create a trigger and use a tag as a condition to Close a ticket however, please kindly note that once a ticket is Closed, it cannot be reopened nor edited even by agents.
Thanks for your comment. One more question: If I want to not allow a State change to Solved by the end user (client) in general and not with a trigger, can I do it? We need to apply some changes to the form before the ticket is resolved. I just want the agent to be able to switch to Solved after I've written the solution note, for example. I don't want to change Solved (customer made) to Open to apply changes to the ticket because the customer will receive an email notification with the status change.
As of now, there is no native function to prevent the ticket from reopening when an end-user replies to the same ticket. You can prevent this by either manually changing back the status or using business rules like triggers. If you wish to disable end-users' abilities to Solve tickets, I've looked around and found a suggestion by one of our Community members that can be found here. Please kindly note that this is a workaround and not directly provided by Zendesk.
Please sign in to leave a comment.