Product ideas | Community
Skip to main content

Filter by idea status

Filter by product

8849 Ideas

The "Internal Note" and "Autoreply" trigger actions in Zendesk do not allow to post multiple notes or replies.Accepted

Please give a quick overview of your product feature request or feedback and note who in your org is affected by this issue [ex. agents, admins, customers, etc.]. (2-3 sentences)It would be nice to have the ability to post multiple internal or public notes using the native Zendesk functionality described in the following article:https://support.zendesk.com/hc/en-us/articles/6191477770906-Automatically-adding-comments-and-notes-to-tickets-using-triggersCurrently, only the first internal note can be posted when multiple triggers are invoked.This issue affects both admins and agents. What problem do you see this solving? (1-2 sentences) This behavior is counterintuitive and limits the capabilities of the feature, forcing a switch to the API to avoid these kinds of conflicts.It is preferable to post notes using "Ticket > Internal Note" because it provides a rich text editor. In contrast, the API requires raw HTML to be used. When was the last time you were affected by this lack of functionality, or specific tool? What happened? How often does this problem occur and how does this impact your business? (3-4 sentences)This problem most recently occurred this week when we switched from posting notes via the API to using the publicly released "Ticket > Internal Note" functionality:https://support.zendesk.com/hc/en-us/articles/8763325557018-Announcing-the-general-availability-of-autoreply-and-internal-note-actions-in-ticket-triggers.Although two separate triggers were meant to post internal notes, only one note was successfully posted. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)The possible workarounds are as follows: Posting notes via the API. Limiting the number of notes to one across all triggers.  What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)The ideal solution would be the ability to post all specified internal notes or public comments defined in trigger actions without limitations.

Allow custom views or filters for Suspended Tickets by suspension reasonIdea Submitted

Would it be possible for Zendesk allowed administrators to create custom views or filters for suspended tickets based on the suspension reason. Currently, the Suspended Tickets view shows all suspended tickets together, regardless of why they were suspended. This includes spam, automated replies, bounced emails, and other system-generated messages. There is no way to filter or create a view for specific suspension reasons. You can sort but that isn't always that helpful. With Zendesk’s newer email verification requirements, this limitation will become more noticeable operationally. When a request is submitted from the Help Center by a user who is not signed in, the ticket is placed into suspended status until the user verifies their email. These tickets can represent legitimate support requests that simply require verification before opening. However, because the suspended queue also contains large amounts of spam and automated messages, it is difficult to quickly identify these verification-related tickets. We also have a external support email that will get a decent amount of spam and/or auto replies that tend to clog up that view.  Being able to create a custom view that filters suspended tickets by suspension reason would allow teams to: Monitor verification-related submissions more effectively Troubleshoot situations where users believe they submitted a ticket but it has not yet opened Reduce time spent scanning the entire suspended queue This functionality would make the suspended ticket queue significantly more usable for operational monitoring and troubleshooting. Thanks! 

Why will Anonymous Requester Verification be mandatory? Please make it optionalIdea Submitted

Zendesk recently announced the upcoming introduction of Anonymous Requester Verification for Help Center requests. While the security motivation is understandable, making this feature mandatory could create serious problems for existing workflows.→ https://support.zendesk.com/hc/en-us/articles/10360295453082-Announcing-verification-for-anonymous-help-center-requests Many organizations intentionally allow anonymous ticket submissions for legitimate reasons — such as embedded webviews, lightweight support forms, or systems where user identity is already handled outside of Zendesk. With this upcoming change, those workflows may be forced to redesign their entire support flow, even though they are currently working without issue. What makes this even more confusing is that Zendesk already allows administrators to control whether anonymous users can access the Help Center at all. If admins can decide that, why are we not allowed to decide whether anonymous request verification should be required? Right now this feels like a forced security policy with no flexibility and no clear migration path for organizations relying on anonymous submissions. If this feature is intended to improve security, it should be implemented as a configurable option in Admin Center, not a mandatory requirement. Please allow administrators to enable or disable Anonymous Requester Verification based on their own workflow and security requirements.

Feature Request: Ability to Set Zendesk Talk Queue Wait Time to Zero MinutesAccepted

Please give a quick overview of your product feature request or feedback and note who in your org is affected by this issue [ex. agents, admins, customers, etc.]. (2-3 sentences)We would like Zendesk Talk to include an option to set the queue wait time to zero minutes. This feature would mainly impact our customers and agents. Allowing a zero wait time would prevent customers from waiting in a queue when an agent is unavailable.What problem do you see this solving? (1-2 sentences)Currently, the shortest wait time that can be configured is one minute, which still places customers in a queue. A zero-minute option would allow calls to bypass the queue so customers do not wait unnecessarily.When was the last time you were affected by this lack of functionality, or specific tool? What happened? How often does this problem occur and how does this impact your business? (3-4 sentences)This issue occurs regularly when our phone queue becomes busy. Customers are placed in the queue and may wait for several minutes, even when agents are unable to answer the call. In many cases, the call eventually goes unanswered, which creates a poor customer experience. This impacts our support efficiency and customer satisfaction because customers spend time waiting without receiving assistance.What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)The ideal solution would be the ability to set the Zendesk Talk queue wait time to zero minutes. This would allow calls to skip the queue entirely so our team can return the call later instead of keeping customers waiting.

[Feature Request] Sorting, Filtering, and Grouping by Lookup Relationship Fields in ViewsIdea Submitted

Overview of Feature Request & Affected RolesWe are requesting the ability to sort and filter tickets using Lookup Relationship fields (LURPs) within Zendesk views.Our organization uses a Lookup Relationship field to designate Subject Matter Experts (SMEs) responsible for certain tickets. This field is critical for routing, collaboration, and identifying tickets assigned to a specific SME.Currently, Zendesk does not allow sorting or filtering by Lookup Relationship fields in views, which significantly limits the operational usefulness of the field for reporting and ticket management.Affected roles include: Support Agents Escalation Teams Subject Matter Experts (SMEs) Support Managers / Operations Leads These teams rely on Zendesk views to efficiently locate and manage tickets tied to specific SMEs.What problem does this solve?Without the ability to filter or sort by a Lookup Relationship field, teams cannot easily identify tickets associated with a specific SME.This creates several operational challenges: Agents cannot quickly locate tickets tied to a particular SME. Teams must manually search through multiple pages of tickets to find relevant items. Escalations and SME collaboration are slowed. Operational reporting and workload visibility are limited. The Lookup Relationship field is designed to model relationships between records (such as SMEs), but the inability to use it in views, sorting, or filtering prevents it from functioning as a practical workflow tool.When were you last affected? Frequency & Business ImpactThis issue occurs daily for teams managing SME workflows.Our teams frequently need to locate tickets associated with a specific SME, particularly when: Following up on escalated issues Reviewing SME workload Coordinating cross-team troubleshooting Managing ticket queues tied to expertise areas Because the field cannot be filtered or sorted, agents must manually navigate through multiple pages of tickets, which increases time spent locating tickets and introduces inefficiencies in ticket management.At scale, this results in: Lost productivity for support agents Delays in issue resolution Reduced visibility into SME workloads Current Workaround (if any)Currently there is no effective workaround that preserves the benefits of Lookup Relationship fields.Possible alternatives have significant drawbacks: Manual searching through ticket pages, which is time-consuming. Replacing the lookup field with a dropdown or user field, which removes the relational data benefits and increases maintenance overhead. Using additional tagging or manual data entry, which introduces inconsistency and administrative burden. These workarounds reduce the value of Lookup Relationship fields and create additional operational complexity.Ideal SolutionAllow Lookup Relationship fields to be used in Zendesk views for filtering and sorting, similar to other ticket fields.Ideally, Zendesk would support: Filtering views by Lookup Relationship field values Sorting views by Lookup Relationship field values Using these fields in view conditions and column sorting Optional: exposing these fields in Explore reporting filters This enhancement would allow teams to fully leverage relational data in Zendesk while maintaining efficient ticket management workflows.

Add trigger conditions for "tag added" and "tag removed"Idea Submitted

Please give a quick overview of your product feature request or feedback and note who in your org is affected by this issue [ex. agents, admins, customers, etc.]. (2-3 sentences)Currently there are trigger conditions that test for tags on a ticket (or not on a ticket). I want to have triggers that fire when a tag is set or when a tag is removed.What problem do you see this solving? (1-2 sentences) Trigger conditions for tags apply to current ticket status, not to tag changes.  When I want a trigger to fire only when a tag gets set on a ticket, I have to create a 2nd tag to prevent the same trigger from firing the next time the ticket is updated, for some completely different reason.For example, if I want to send an email to an Agent when a specific tag gets set, today I need to have a condition that tests for the presence of that tag (e.g., tag1) and the absence of a secondary tag (e.g., tag1_notification_sent), and then the action sends the email and sets the secondary tag. Without the secondary tag, the email would get set every time the ticket is updated as long as tag1 is on the ticket.A trigger condition that activates only when the tag is set, not simply because it's present, would remove this overhead and tag-clutter. A corresponding condition for tag removal would be equally useful.When was the last time you were affected by this lack of functionality, or specific tool? What happened? How often does this problem occur and how does this impact your business? (3-4 sentences)I have numerous examples of “blocker tags” in my triggers to prevent redundant notifications. I was looking at adding another trigger today that would fire when a tag was set and decided to not do it because I didn't want to add yet another secondary tag to clutter up the ticket's tags.Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)The only workaround is to use a secondary tag.What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)Ideally there would be options for Ticket > Tags akin to Changed/Changed from/Changed to, etc for Ticket > Status category, such as “Added at least one of the following”/"Removed at least one of the following"