Occasionally a system administrator, or manager, may have the need to close a large number of tickets. For example, they've taken over from someone and have found that the previous person wasn't good at having agents close tickets, instead just leaving them in a "Waiting" status.
It's possible to mass close tickets a few different ways, but there are a few things to consider before doing so:
- When tickets are closed, generally a notification is sent to the ticket sender letting them know the ticket was closed. Will this be an issue? If so, additional steps need to be taken.
- Do you want to preserve ticket timings? When a ticket is closed, it's timing (e.g., Idle Time) is affected. That means reports can show drastically different information post close as opposed to pre-close.
- If closing tickets via the database directly, what database is being used? Queries will vary based on the database being used. (E.g., MySQL versus Postgres.)
- Are all of the tickets in the same department and/or group, or do they vary? If they're all in the same group and/or department, the process is a bit easier than if they're scattered, especially if you are editing the database directly.
- How do you want to close the tickets? Via the SmarterTrack interface or via direct editing of the database? If the latter, remember point #3. Using the interface will preserve timings, but it can be a bit more labor intensive.
Below are a few different ways you can mass close a number of tickets at the same time, as well as some things to consider, and some workarounds.
Via the SmarterTrack Interface
You can select a number of tickets and change their status to "Closed" via the Actions (3 vertical dots) dropdown. Doing this will not only close the tickets, but, it will send the close notification. That may or may not be an issue.
To get around sending the notification, you'd want to FIRST disable SMTP for the department. Then, after you do your mass close, you'll need to go to the Spool (Settings > Spool) and delete any new items put into the spool once the tickets are closed. After this is done, you can re-enable SMTP for the department.
Of course, the main issue is if agents are actively working tickets in that department or group. If they are, you run the risk of deleting active ticket responses. So it may be wise to disable SMTP and wait for the Spool to clear before making your mass close.
Alternate Solution Via the SmarterTrack Interface
To get around having to disable/re-enable the SMTP account for a department, or if you're wanting to close tickets from multiple departments, you can create a new Department called something like "Archive" or "Clean Up". (If you don't want notifications sent, you wouldn't set up any email accounts for this department.) Then, you transfer any tickets you want to close to that new department and close them.
The main issue with this method is reporting. You would have all of these tickets transferred out of a department and into the new one, and the new Department would show up on any reports you're running. If that's not a concern, or if you can easily explain it away to any higher ups, then perhaps this isn't an issue.
Via the SmarterTrack Database
This can be done if you're adept at creating SQL queries. The main issue here is potentially needing to get the ticket numbers for all tickets you want to close, and then adding them to the query you've crafted. This would be necessary if the tickets are across multiple Groups or Departments. Then, of course, there's the issue of the type of database being used. MySQL and Microsoft SQL are, basically, the same. But if you use Postgres, that's a different beast altogether. For example, a SQL-specific option of GETUTCDATE() is used in the SQL query, but other database types use a similar, but different, function.
If the tickets are in the same group and/or department, and they all need to be closed, it's a bit easier as just a single query would work. If only some tickets in a specific group or department need to be closed, you'd need those ticket numbers and craft your query for the specific group or department.
Finally, when editing the database directly, there's an issue of "timings". (E.g., Avg. Time Open and Active.) These won't be adjusted, which could throw off reports. However, as these tickets were never closed to begin with, perhaps that's not an issue.
So, as you can see, you have some options. If you have any other questions, please feel free to let us know.