In the Ticketing: Overview article we covered the basic features and usage of the Ticketing page in Sonar. In this article, more advanced features will be showcased, including where to find them, what they look like to an administrator or to users, and how best to leverage these features to simplify your actions in the ticketing interface.
Mass Editing Tickets
The process of editing individual tickets was covered in the Ticketing: Overview article, however, it can also be taken a step further. Mass editing tickets allows you to select a group of tickets and make changes that will occur on each of them. In order to initiate a Mass Edit of your tickets, simply check the box next to each ticket you wish to edit:
With each box that gets checked, the ticket name will be added to a banner at the bottom of the page:
Once you've selected all the tickets you want to edit, click on the edit button located at the end of the banner:
If you've read through the Inventory List View: Overview article, the "Edit" modal that shows up will appear to be very familiar.
This Edit Tickets modal has a number of fields:
The Entity selector allows you to modify the Account or Network Site the ticket is assigned to.
The Status selector allows you to modify the status of all the tickets you've selected for mass modification. You can choose between:
Closed
Open
Pending (External)
Pending (Internal)
The Priority selector allows you to modify the priority of all selected tickets. You can select from:
Critical
High
Low
Medium
The Due Date selector allows you to set a specific date that all selected tickets are due by.
This section will list all tickets that will be edited by these changes. Once the "Edit Tickets" modal is open, you can no longer remove or add tickets.
The changes made in this modal will apply to all tickets, you can't selectively make changes to tickets within those selected.
Unlike Using Parent Tickets, mass editing tickets doesn't allow you to add comments or details concerning why changes are being made. The changes are simply made, and will only appear in the logs of each ticket.
Prevent Tickets from Reopening after X days
In previous sections and articles surrounding the Ticketing feature of Sonar, manually managing tickets has always been the only way of controlling their behavior. Whether on an individual basis or in bulk, replies, assignments, and closing the ticket all needed to be initiated by a user. Sonar does provide a small measure of automation in managing the path for tickets that have been closed and receive a new reply.
The default behavior will be to reopen the ticket and have the new reply appended to the existing message history. This will occur indefinitely, as long as the original subject line remains in place. By following the below directions, you can configure this behavior to place a limit on how these reopened tickets should be handled:
Go to Settings
Expand the Ticketing section
Click on General
This will allow you to modify the number of days a closed ticket needs to stay closed before a new reply will not re-open the ticket.
With this setting configured, new emails received in existing ticket chains will create new tickets, rather than appending the new reply to an existing ticket and reopening it.
When This is Useful
Controlling how and when tickets can be reopened by a customer is useful in managing unrelated issues. There are always certain customers who will continue to default back into using the email they've previously received. This can mean tickets being reopened months later simply because it was the most convenient way for the customer to reach your team, even when the new cause for contact is unrelated to the original one.
By forcing new tickets to be opened after a certain number of days, you enable each conversation to be on-topic and simplify the process of troubleshooting or resolving the issue at hand, as the ticket is free of any cumbersome history.
Currently Viewing
In best practice, the user assigned to a ticket is the party who will be responsible for seeing that ticket through to completion, or the next point of escalation. However, circumstances may arise that would prompt another user to interact with the same ticket. In these scenarios, another user may be in the process of detailing vital information via a new comment at the same moment that the assigned user is typing a reply to the customer with now inaccurate information.
The Currently Viewing feature allows you to see if another user is viewing the same ticket as you, by displaying the user's avatar at the top-right corner of your instance - hovering over the avatar will display the user's full name. If the user is actively typing a comment or reply, another icon will also be visible and is used to indicate that a response is being written by another user. With indicators like these, you can help to eliminate duplicate efforts and contacting customers with outdated information.
Merging Tickets
Merging tickets in Sonar allows you to combine the conversation history and contents of two or more tickets into a single ticket. In order to merge tickets together, you'll need to ensure they're assigned to the same account or network site and you'll need to do the following:
From the Ticketing interface, locate the ticket you'll use as the host (or main) ticket
Expand the dropdown next to the Edit button and select "Merge Ticket" from the list of actions
From the modal that appears, select the ticket to be merged from the dropdown
You can filter and search by typing in either the ticket id or the ticket name.
The filtered list that appears in this modal will show all tickets that are assigned to the same account or network site (excluding the ticket you're currently using as the host). In this example, all tickets assigned to Peter Parent's account are displayed.
If the ticket you selected as the host ticket isn't assigned to any account or network site, this list will display all other tickets in your instance that are similarly unassigned, up to a maximum of 50, which can be further refined by entering search terms.
Once you have the ticket selected, click the "Merge" button
The conversation history of the merged ticket will now appear in the list on the host ticket in addition to a note within the ticket that the merge occurred.
When This is Useful
Merging tickets occupies a functionally similar role to Child Tickets, however, there are a few distinct use cases where tickets could be merged instead of added as a child ticket:
If a customer is creating a new conversation/ticket with every reply, whether as a result of cc'ing a different mailbox or simply sending a new email rather than a reply. In this case, the new ticket should be merged rather than treated as an independent child ticket.
If an internal tracking ticket is being used for network outages, you can simply merge alert emails or notices into a master ticket to capture relevant details rather than having multiple similar tickets open.
Essentially, merging is useful when the information and conversations contained within a ticket can easily be grouped together in one main ticket, while child tickets are used when multiple similar customer tickets exist and each customer should receive a reply.
Considerations When Merging Tickets
Merged tickets have two caveats to them:
When a ticket is merged, its description will be overwritten - only the description of the host ticket will remain after merging.
Once a ticket is merged, it's impossible to separate the 2 tickets. The merged ticket ceases to be accessible once the merge is complete.
Updated
by Mitchell Paul-Soumis
If the ticket you selected as the host ticket isn't assigned to any account or network site, this list will display all other tickets in your instance that are similarly unassigned, up to a maximum of 50, which can be further refined by entering search terms.