In Zendesk Support, tickets are solved first and then, after they have maintained their solved status for a predefined amount of time (set up in your automations or triggers), they are moved to closed. The major differences between solved and closed tickets are the following:
- Solved tickets can be reopened and updated.
Tickets can be marked solved by agents. Tickets marked as solved, then responded to by an end-user will be reset to an open status.
Tickets in solved status, that are not closed by a trigger or automation, are automatically closed after 28 days, regardless of whether there have been updates to the ticket in that timeframe. - Closed tickets are locked. They cannot be reopened or updated in any way.
Tickets can be closed via a trigger or automation, but not by agents. Tickets marked as closed, then responded to by an end-user will create a new, follow-up ticket.
Note: Agents can also create a follow-up ticket from a closed ticket that will include a link to the closed ticket (see Creating a follow-up for a closed ticket).
Zendesk Support comes with an automation called' Close ticket 4 days after status is set to solved.' This automation gives end-users 4 days to respond to a solved ticket before the ticket moves to closed status. You can set this automation to run anywhere between 1 hour and 28 days.
Best practice guidelines recommend that you leave a ticket in solved status for 3-5 days before moving to closed. This allows end-users to re-engage with you in the same ticket. If you deactivate the "Close ticket 4 days after status is set to solved" automation, your solved tickets will be set to closed by a system action (noted in your events and notifications as a 'batch close') after 28 days of inactivity in solved status.
After 120 days of being Closed, tickets are automatically archived (see Ticket archiving). Archiving tickets speeds up the loading time for views, especially those views that include multiple tickets which have been closed for a long period of time (see Using views to manage ticket workflow).
35 Comments
The automatic solving of tickets within some timeline arbitrarily set by Zendesk is a problem for Zendesk customers and a practice they should discontinue for all the reasons above. But beyond that, your system allows admins to create automations that would seem to allow us to extend the number of days/hours after solving that a ticket is closed. I created one that would give us 45 days after the status was set to solved before the incident was closed. I recently tried to update a ticket that had been set to solved <30 days. That's when I discovered my automation was completely meaningless, and Zendesk had systematically closed it on the 28th day.
Yeah I have similar thoughts as Debbie. I'm not too bothered about the hardcoded 28 day limit (Zendesk is a hosted solution, so it's your call), but it would have been nice if this was made clear in the Automations section of the dashboard. I setup a 60 day automation to close solved tickets a long time ago, thinking that this was working.
@Zendesk: Why don't you make the "close solved tickets after x days"-automatisation UN-deactivatable?
Put a note in the "close solved tickets after x days"-automatisation's settings, telling the customer why the automatisation is hardcoded and that its maximum is 28 days.
Doesn't solve the problem for a lot of customer here but would probably prevent future confusion.
Hi Johannes!
That's a really good suggestion, and I know that this has been a pain point for other customers as well. I'll pass it along!
Unfortunately, I just discovered this 28 day batch CLOSE that occurs and have been reading about it in these forums.
I see that this forum seems to have dropped off in August of last year and I feel it needs to be brought back up.
We have been on ZenDesk for about 12 months now/ We disabled the CLOSE trigger shortly after stating because we often go back and add reporting fields to tickets so we can cull out new, pertinent metrics for our organization. Even though the working the actual support ticket is complete we are in not DONE with it. Because we cannot add new fields and set their values to a CLOSED ticket, we only use SOLVED.
I briefly looked into adding new status to our system but I was told this would throw off many of the internal automation that I did use so we adjusted our process to accommodate the system.
It is not prudent in any way, shape or form for a tool like ZenDesk to set any arbitrary timeline when you consider something in my system CLOSED. That is neither your role nor should it be your prerogative.
I completely understand setting it up as a default; however, I as an admin in my organizations ZenDesk application should be able to turn it on or off like can any other trigger. You cannot set our business rules and you do not know how a hard rule like this impacts us.
we need to change the date to 45 days as we often need to change incidents to tasks etc for reporting purposes 28 days is to short
Hi-
If tickets status are submitted as solved, will the customers receive an email with comment in it? was thinking that customers wont receive anymore update once its submitted as solved.
Hi Beth -
Apologies for the delayed response, but welcome to the Zendesk Community!
After a ticket has been marked as solved, a customer will still receive an email if a public reply is submitted to the ticket. They will not, of course, if an internal note is added.
Let us know if you have any additional questions!
Niki Lentz,
Did you determine that you COULD disable the close, or the batch overrides that setting?
Were you able to determine any sort of work around to atleast extend the number of days before it closes?
It looks to me like I can extend the date before a ticket is closed in the automation. Can I set the number of days to 60 as shown in my screenshot? Or, is there something else that will override this automation and close tickets after 28 days?
I believe the max is 30 days but I could be wrong.
Welcome to the Community, Nate! It looks like you've been pretty active the last few weeks...we're glad you're here. :)
Heather is pretty close to right...tickets can remain in Solved status for a maximum of 28 days before it's automatically moved to Closed, regardless of whether an Automation stipulates a longer timeframe.
Depending on your workflow and plan level you might be able to leverage the On Hold status to keep tickets from closing before you want them to. Can you tell us more about your process?
DISREGARD- I just realized it's in the automations, not the triggers.
Is that condition "Ticket: hours since solved" a custom one? I don't have that on my drop-down list.
Thanks for the update, Todd. Glad you got it figured out!
A number of people have already commented on this, but with GDPR retention/deletion/etc. it would be nice to revisit this idea again. Ideally, admins could set the solved --> closed timeline via business rules to ensure they comply with whatever regulatory processes affect them in a more granular manner than 'delete everything.'
Hey Matt!
Setting a ticket from Solved to Closed is accomplished by Automation, and you can change the timeframe right from within that Automation. Let me know if I'm misunderstanding what you mean.
Jessie - I was referring to this point in the original post:
A few others have alluded to this same customization replacing the baked-in 28 day maximum. The current issue w/ GDPR compliance is that we can't modify data in a closed ticket, other than deleting the entire ticket and losing all the associated data. I'm proposing that this timeline be customizable by admins, allowing them to set the time when a ticket can still be modified, redacted, etc.
We could probably hack some automation cycle to consistently reopen & solve tickets every 27 days until this process has run X times, but this will distort a variety of system metrics like resolution time, rendering them useless in the current state.
Hey Matt! Thanks for clarifying!
I'll pass your feedback along to the folks working on our GDPR preparations!
by ITIL actually admins should be able to modify also Closed tickets.
Hey Matt, what information would you anticipate needing to alter on a closed ticket, other than the name of the requester? So, for example, if a deleted end-user showed up on the closed ticket they submitted as "Permanently Deleted User", would that be sufficient? Or is there other information that you would need to alter by means other than deleting the ticket?
Honestly, it could be almost any field, description, comment, or attachment. Anything where text can be entered (i.e. not a dropdown field or checkbox) is a potential area that may contain some sort of PII that may need redaction after the fact.
A feature I've requested in the 'Data Retention' portion a more detailed GDPR post would offer a more scalable solution: permanently retain data for all fields an admin knows can never contain PII, then redact/anonymize all other content at some pre-defined interval (where the ticket would likely be closed at this point).
You also need to ensure the IP address and other related metadata found in the event logs are scrubbed as well.
Good point, Amanda. The event log data should be included in the redact everything that's not explicitly retained default behavior.
How long do closed tickets stay in our Zendesk. And is there any possibility to delete them as the cutomer wishes so?
@Marjolijn,
They always going to be in zendesk, but if you wish you can delete them.
@mindaugas Can you tell me how? And is there a way you can delete tickets after a certain time automatically?
Auto-delete: create extension target with URL:
https://[YOURDOMAIN].zendesk.com/api/v2/tickets/{{ticket.id}}.json?ticket[status]=deleted with PUT method and add it to your automation.
how to get a report or a view of who solved a ticket which is solved before.
by updater and text field change
Was wondering why my automation to close tickets after x-days (more than 28) was not working?
Zendesk folks this is not a good process to hard code an auto-close. We have processes where getting a return product back could take more than your 28 day automation.
Need to be a way to disable this please.
Please sign in to leave a comment.