Andrea Moore

The newly added default report filter for the support-tickets dataset needs to either be undone or give users the ability to turn this function off. 

Not every report created is limited to data from the past 30 days. I regularly create reports for all history or specific date ranges. I have never needed to look at the past 30 days worth of data. 

By setting this as a default feature, it creates more work for Explore users as they have to remove the filter. If they do not realize the filter is in place (depending on the visualization type, it's not immediately obvious the filter is on), this could also create inaccurate reports. Inaccurate reporting could have serious business impacts.  

The ticket number isn't a button, but the blue text (the subject line) is a link that will merge the tickets. 

I agree with Anja. Also, having the settings open in a new tab is a bit of an annoyance. My real issue is that most of the settings have either been renamed or categorized differently in the Admin Center versus the old Settings area. It's hard to find what I'm looking for.

@... I don't want to include the agent's email, but the end-user (the ticket commenter). An example of this would be, a customer sends an email to our Customer Service department asking us to place an order and to have their sales rep contact them about renewing their contract. We want to keep the ticket so Customer Service can process the order and send a side conversation to the sales rep asking them to contact the customer. When we create the side conversation and include the ticket comment from the customer, it doesn't include the customer's email address. So the sales rep has to come back to Customer Service asking for that info. It slows down the process. 

Currently, when creating a side conversation, agents have the ability to attach comments from the original ticket thread. The system includes the name of the commenter, the timestamp the comment was made, the text of the comment, and any attachments associated with that comment. It would be helpful to also include the commenter's email address.

We often use side conversations to forward a ticket to a department that doesn't use Zendesk to perform a task that requires them to reach out to the commenter, while keeping the original ticket to perform another task asked by the commenter. Agents have to remember to add in the commenter's email address when creating the side conversation as this info does not carry over when adding the ticket comments. 

Post Title: 

Bulk updating Queries with Tags

Feature Request Summary: 

I would like the option to select multiple queries from my list and add the same query tag to them all at once.

Description/Use Cases: 

The ability to apply a tag to a query didn't exist when I set up the majority of my queries. I know have over 500 queries and would like to use the tag feature to make them easier to find. However, I have to update each query individually to add the tag. This is very time consuming and not practical. 

Business impact of limitation or missing feature:

For companies with a large amount of queries, it would be helpful to have a way of sorting queries. However, without a way to bulk update queries, it limits adoption of the new feature.  

This is functionality that we need to have as part of our business processes. There are several members of higher management that receive a single report once a week to have line of sight into our customer service department. It is not feasible to have our C-suite access Explore just to view one report.

I agree that it would be nice to have the conversation visible where it started in the thread, but I'd also like to be able to print the side conversation separately. Is that a possibility? 

I'm also adding my vote. We have a group we want to add to Zendesk, but their emails are confidential and shouldn't be seen by the other groups. 

This is a major issue for my company. Follow up tickets are also pulling in our custom ticket fields and sending CC notifications to the people cc'd on the original ticket who have nothing to do with the new ticket. There has to be a way to stop this from happening. This seems like a major flaw that needs to be investigated thoroughly and not waiting for upvotes on an enhancement request.