Sara Ledger

@... How are people supposed to track that request if you've marked this post as answered when it is no longer answered but in the backlog? Will you still be posting updates to this post?

@... I already reached out to Support and they said they escalated to Management and the Product team who said this was intentional functionality and that they only thing I could do besides escalating to our Account Manager was to put in a Feedback request. Please see closed ticket #10386510 in your system. I am getting the run around from Zendesk on this issue.

+1 on this. Would be incredibly beneficial to have something similar to assume identity but maybe an assume role so Admins can check the configurations we're working on from that view without creating additional users in the environment.

Is there anything in the works to do a filter for only all new tickets assigned to my groups?

Feature Request Summary: 

Zendesk should not change information in past notes on tickets. This appears to be an issue specifically and only with Talk generated tickets.

Description/Use Cases: 

1. A user calls in to Support, they are not an authorized contact for their company. The agent redirects them to their internal Help Desk on the phone and sends the ticket to their authorized contact(s) to let them know a non-authorized contact reached out to Support.

2. An original caller is going to be away for an extended period of time (ex. honeymoon, sabbatical, maternity/paternity leave, etc.) and needs another user from their organization to take of the ticket.

3. An original caller is moving to another position in their company/retiring/has passed away and we are transferring the ticket to the person taking over their responsibilities.

- In each of these cases, Zendesk is changing the To caller field in the past call notes to whomever the current requester is, regardless of whether or not that person actually made that call or if that phone number is even associated with that profile.

Business impact of limitation or missing feature:

This is critical issue for our business as all of these are very common use cases.

The call should state who actually called and remain that way no matter what changes are made on the ticket in the future since that is the result of that call at the time that call was made. It makes it seem like people called in that did not call and that phone numbers that the call was made from are their numbers when they are someone elses entirely which causes misinformation.

We have never encountered another item that automatically changes past information when a requester is changed. Even on a non-Talk ticket, if I change the requester, it does not change that the original message came from the current requester, it stays the original requester. 

Talk tickets have lost this parity and are providing false information as a result. What is the point of being able to change the requester on the ticket if it updates information NOT from that requester elsewhere on the ticket? We lose that history and cause confusion. 

This issue is ONLY present in Talk generated tickets and does not parity with how the Support tickets currently function.

We are a national company and this is a major issue for us due to multiple states requiring two party consent for recording. This is a legal issue that we need to provide an automated message for to cover our teams and avoid potential repercussions if our agents do not state the call may be recorded.

Created a new Feedback item for the request in multiple comments to separate the redaction and delete ticket permissions: https://support.zendesk.com/hc/en-us/community/posts/4574626017050-Separate-Permissions-for-Deleting-and-Redacting-Tickets

Feature Request Summary: 

The Permissions for deleting tickets and redacting content on tickets should be separated into two different permissions. 

Description/Use Cases: 

We need to allow our agents to have the ability to redact sensitive content immediately from tickets which could cause security issues such as Passwords, API Keys, Credit Card Information, etc. without having to wait for a higher level of agent or admin to have the time to remove the sensitive information.

These same frontline agents should not be able to delete tickets since that cannot be tracked and reported on like redacting content can. 

Business impact of limitation or missing feature:

This is a necessary need for us so sensitive information can be redacted as soon as possible versus waiting for a higher authority to have time to redact the information.

Other necessary information or resources:

This has been requested multiple times in the comments of this post: https://support.zendesk.com/hc/en-us/articles/4408846470170-Redacting-ticket-content-in-the-Zendesk-Agent-Workspace 

Jun Qin - Since you can't blank out follow up tickets, we have a trigger to blank out follow-up tickets. 

When it meets the below all conditions, we have a Remove Tags action to remove the tags associated with various fields. You could have the Remove Tags action remove your customer priority field tags. I have this setup for our custom priority field on our system (the low, medium, high, urgent tags) and it works great to blank out the fields. 

This has been a great work around for our needs!

Feature Request Summary: 

Requesting the ability to have an End-User switch to enable/disable Dark Mode in their instance of the Guide. For example, a toggle on their profile.

Description/Use Cases: 

Customers have been requesting a way to have the Guide have a Dark Mode option for accessibility and ease of eye strain. 

Business impact of limitation or missing feature:

Many of our customers do not have the luxury based on their company security policies to add apps to their computer browsers to have a global browser dark mode. Having this option from our application end would help to improve satisfaction of the product and encourage use of the actual Guide versus our email or phone Support options. 

Other necessary information or resources:

Discovered posts for Sell and Support but didn't not see one for Guide.