Discuss ideas, submit feedback, and track what's next
Help us understand your request
An intake-ready template
Feature Request SummaryPlease provide the ability to hide the requester's IP address and/or region in the Support product.Use CaseI understand that collecting the IP address is required, but I do not understand why this needs to be shown to the agents. To help protect the requesters PII, we should be able to limit who has access to this information.Product limitation or missing featureAbility to prevent the agents from seeing the requesters IP address.Business impact of limitation or missing featureI cannot currently limit this access.Other necessary information or resourcesI would like to have a setting in Admin to hide the IP address and / or Location in the event log metadata footer.
Zendesk Talk callback confirmations are currently limited to one static language per phone line. In multilingual environments where a single phone line serves callers in multiple languages, the callback confirmation message cannot be presented in the caller’s selected language.Even when callers explicitly choose a language via IVR, the callback confirmation language is still determined solely by the phone line, not the caller’s selection or session context.Business ImpactThis limitation creates a customer experience gap in multilingual regions, where: Callers clearly select their language in the IVR But receive a callback confirmation in a different language Leading to confusion, repeat calls, and reduced trust in the callback feature As a result, teams are forced to either: Accept a degraded callback experience, or Disable callbacks entirely, or Add operational overhead by splitting traffic across language‑specific phone numbers Example Use Case A caller selects Spanish in the IVR They choose to request a callback The system confirmation plays in English because the phone line is configured for English The caller is unsure whether the callback was successfully scheduled This occurs even though Zendesk already captured an explicit language preference earlier in the call flow.Requested EnhancementSupport language‑aware callback confirmations, such as:Option A (Preferred):Allow callback confirmation language to be determined by the caller’s IVR language selection or session contextOption B:Allow multiple callback confirmation greetings per phone line, selectable via IVR routingOption C:Allow custom audio upload for callback confirmations, similar to other Talk greetingsAny of these options would allow organizations to deliver a consistent, localized callback experience without duplicating phone lines.Why This Matters Multilingual support is a core Zendesk strength across Support, Guide, and Messaging Callback confirmations are one of the last Talk experiences that cannot be localized This disproportionately impacts regulated or bilingual markets where language accuracy is not optional
Hello, Following guidance received from Zendesk Support, we would like to formally request several enhancements to improve the functionality and flexibility of Digital Lines.1. Integration with Third‑Party BotsCurrent limitation: Digital Lines cannot be connected to third‑party conversational AI platforms.Request: Enable an integration mechanism (API, webhook, or connector) allowing Digital Line interactions to be routed through external bot platforms before reaching agents.2. External Triggering and ConfigurabilityCurrent limitation: Digital Lines cannot be initiated via external widgets or by passing a line_id.Request: Provide configuration options to trigger Digital Line calls programmatically through external scripts, widgets, or APIs.3. Independent Placement of the Call ButtonCurrent limitation: The Digital Line button can only be used within the Zendesk Web Widget.Request: Allow the call button to be deployed as a standalone component that can be positioned anywhere on a website.4. User Identification for Authenticated VisitorsCurrent limitation: All calls appear as “Caller Unknown,” even for authenticated users.Request: Allow authenticated session data (email, external_id, user_id, JWT) to pass through to Digital Line calls to improve agent context and reporting accuracy. We believe these enhancements would significantly improve Digital Lines’ usability, integration capability, and overall customer experience.
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)Recently, Zendesk updated AI Agents - Essential for email/web form to add a "Did this resolve your issue"?" prompt to the AI Agent's autoreply. If the requester clicks the “No, I still need help” button in response to this prompt, ZD sets a tag on the ticket and adds an internal note to the ticket stream but does not notify the Assignee that this happened. This behavior needs to be corrected.What problem do you see this solving? (1-2 sentences) Before this new capability was added, the requester would reply to the AI Agent's autoreply with some form of “I still need help”, which would cause the Notify assignee of comment update trigger to fire, instructing the assignee to follow up with the requester. The “No, I still need help” button is simply a shortcut for the requester replying to the email. Yet the assignee isn't notified. The requester thinks that their ticket will get attention based on the button click, but the assignee has no idea that the button was clicked. This is fundamentally flawed, especially since the button click causes an internal note to be added to the ticket stream without activating the Ticket > Comment / Is / Present (public or private) trigger condition.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)In most cases, there won't be an assignee for a ticket with an AI Agent autoreply. We've implemented an SOP to “defer” tickets with AI Agent autoreplies, after confirming that the autoreply is on point and not something that requires manual Agent involvement. This SOP has appropriate triggers to notify our Agents if the requester replies and I adjusted those for the button click instead of an emailed reply when this feature was introduced. But in a couple of instances, one of our Agents took the ticket rather than deferring it, and they received no notification when the requester clicked No, I still need help, as I assumed the Notify assignee of comment update trigger would take care of that. When we discovered that this wasn't happening, I submitted a ticket on this, because it's clearly a bug. Unfortunately, yet again Zendesk has decided that something that's clearly a bug is actually working as intended, and so I have to submit an enhancement request to ask you to fix the bug.Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)I built a secondary trigger that checks for the ar_marked_unhelpful tag being set and use that to send a notification to the assignee if there is one. Unfortunately, because of the way tag conditions work in triggers (testing only for presence, not for the tag being set), I also had to clutter up the ticket tags by adding a “blocker” tag to keep the notification from being sent after every update once the requester has clicked that button.What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)The Notify assignee of comment update trigger should properly fire based on the internal note that's added to the message stream when the requester clicks “No, I still need help”.
There was a recent Zendesk QA Calibration Dashboard update made at the end of January that removes the visibility and readability that the previous dashboard provided. Having the side-by-side comparison grid proved to be invaluable to my team. The update was mentioned in a post here but further details were never delivered, as promised, and therefore the update was launched without mention of what would be changing. I understand the desire to make the dashboards look similar, but at this point, it just muddies the waters on what we are actually trying to compare. At this point, I have to export the data myself and manipulate it to get meaningful results from the new Calibration Dashboard. Please revert it back to the simple color-coded grid of before.
I think it would be really helpful if Zendesk allow us to view ticket in Kanban. I think it's a pretty basic thing for a ticketing system. It will make our agent see their task more easily in 1 view, instead of multiple view with different filtering
We have a use case where we need to be able to use a trigger to create a side conversation that not only has the boiler plate text we want (which is already easy and possible) but contains the original email's attachments that were sent with the email that came in through the email channel to create the ticket. We have another group of people who are not Zendesk users who for certain tickets, need to have notification sent to them with the original email's PDF so they can do OCR on it (this is for invoices). Looking for a Roadmap possibility of adding a way to have a trigger add attachments to the side conversation a trigger can generate.
At our company we're really missing the functionality to directly link to a specific comment in a ticket. We use solely Zendesk for communication with our customers. While working on complex issues a ticket can easily see 20-30 replies. When pulling in other people throughout our company using GitHub issues we link to the Zendesk ticket for reference, but we can't link directly to the relevant comment. This becomes a time-wasting nuisance for people who have to read through the entire ticket until they reach the part that's relevant for them. It would be great if Zendesk could create linkable elements within a Ticket that allows people to jump to it directly. A few examples that illustrate directly linkable responses/comments/post from around the internet: * http://stackoverflow.com/a/27860061/183622 * https://groups.google.com/d/msg/golang-nuts/yGGEeqJvG0M/9s6HEnnDAQAJ * https://twitter.com/terrorobe/status/785483868879122433
As users increasingly use AI Agents like ChatGPT or Claude to troubleshoot, Zendesk-hosted help centers have two accessibility problems: Direct fetch is blocked - when an agent tries to access a help center URL, Zendesk's Cloudflare configuration returns a 403. The agent never sees the content. Web search returns stale content - when agents fall back to web search, they get whatever was last indexed. If a topic recently changed in our knowledge base, the agent may end up returning inaccurate, out-of-date answers from the stale search cache. Zendesk should introduce an admin setting to host a `/llms.txt` file at the root of the help center domain. Publishing an llms.txt file would give AI agents a structured index of help center content optimized for LLM consumption. Ideally, Zendesk would also consider allowing verified AI crawlers through Cloudflare for help center content, since this is public documentation intended to be found. At a minimum, it'd be nice if we could add instructions to the llms.txt for agents to direct them to an agent-accessible source of help content.
As a team relying heavily on article labels for content management in Zendesk Guide™, we'd like the ability to report on article labels in Zendesk Explore™.
Hello Team,I have been a part of the EAP testing of the AI translations and feel that I had provided sufficient and detailed feedback during testing in my sandbox.I just saw the announcement that GA has begun yesterday and is expected to finish next month, which is very exciting and made me go back to the feature to see how polished it has gotten.Unfortunately in the 5 months since I shared the feedback, not much seems to have improved and my excitement suddenly turned into wonder why it is being rolled out in its current state. Previously I had flagged the following issues:- If the Translator tool was turned off, there was no indication at all that a message was translated. This was fixed and you now have the “Show original” and “Show translation” messages displayed at all times, even if the Translator is turned off. The issue is that there is still no indication in the “Events” tab that a translator was used. Since the “Events” tab is basically an Audit Log for the main tab, it should be expected that Translations will be mentioned there as well.- No option to Translate proactive messages - the new translations work only if you have the ability to turn on the Translator tool. This feature is not available on proactive tickets, meaning that the tool cannot be used until we receive a response from the customer. This button you also mention in the article "To preview a translated message before sending, click the Translate button in the ticket composer." is not available.- Text formatting and spacing breaks - you can see in my original email, each paragraph has single row spacing, but the translated version has double row spacing. The doble row spacing is also seen in the end user's mail.:- Translations in Zendesk QA: I had requested a way to check if the email was translated in Zendesk QA, so that the QA agent knows if you sent a translated version (as one should in foreign language tickets), or not. Without this function, QA agents have to do extra steps by opening the ticket in Support.Thank you for the time and I hope these requests are fulfilled as soon as possible as they should be part of the feature as soon as it is GA.
Hallo Zusammen, leider hat sich meine Ansicht bei der Ticketbearbeitung geändert.Obwohl ich die gleiche Berechtigung habe wie Ben Pfitzner sieht er in seiner Ansicht die Absender E-Mailadresse ich sehe aber nur noch die Shopify App und die Review App (siehe erste Grafik.Bei meinem Kollegen wird die E-Mailadresse angezeigt, welche ich leider weiterhin benötige.Desweiteren sehe ich den Verlauf des Tickets nicht mehr, ob der Anfragenden bereits schonmal eine Antwort von mir erhalten hat etc.Wie und wo wurde das geändert? Danke für die rasche Rückmeldung
Upon trying to save an article we've just edited, we're sometimes getting this message, as if we're x'ing out of the page without trying to save: “Leave site? Changes you made may not be saved.” There's the option to Leave or Cancel. If you click Leave, the changes aren't saved. If you click Cancel, the box just pops up again. A couple of us first started seeing this about a month ago. Another person on my team had seen it months earlier than that. We've had to redo changes on many occasions. The only “workaround” is to copy the changes we just made (the whole article's HTML if the changes are widespread) so if it happens, we can get them back without starting from scratch.
Hello, I would like to be able to create Article Templates in Guide or to Clone Articles.The goal will be to uniformize our contents. More or less like Content Bloc, I would like to have a category hosting several Templates , and editors has to choose a template before going. I would like also to be able to changes/ Look for some words or key words in all articles and be able simply to modify them.For Example, the name of my product changed, and now I have to update all article one by one.. Thanks
I inquired about the following and was advised by support to submit product feedback for enhancement consideration. Is there a way for out of office email responses (auto-replies) to be recorded within a Zendesk ticket as a comment? The Out of Office app requires agents to set themselves as out of office within Zendesk which doesn't work for us. We simply want to capture the out of office auto-reply email (Gmail) within the ticket so that the agent who sent it can be notified in the ticket instead of monitoring email separately and assign it to someone else. Support felt there that there would be value in a feature to keep agents in the loop of Out of Office notifications sent through external email.
Hi Zendesk team, Zendesk already provides HTML comment placeholders like {{ticket.latest_public_comment_html}} and {{ticket.latest_comment_html}} that return properly rendered HTML when used in email notifications. However, as documented, when these same placeholders are sent to a URL target or webhook, unformatted text is used instead of HTML. This is a significant limitation for third-party integrations. In our case, we sync Zendesk ticket comments to Freshservice. Agent signatures contain rich content (bold text, images, links, horizontal rules) that renders correctly in HTML. But when sent through a webhook, the HTML placeholders are stripped down to plain text, leaving raw Markdown syntax like , **, and --- visible in the receiving system.The irony is that the data already exists in the right format — the Ticket Comments API returns a perfectly rendered html_body field. But since webhooks don't preserve the HTML formatting of these placeholders, we're forced to set up an external middleware (Power Automate, Lambda, etc.) that:1. Receives the webhook with just the ticket ID2. Makes an extra API call back to Zendesk to fetch the comment's html_body3. Forwards the HTML to the third-party systemThis adds unnecessary complexity, latency, and an additional API call per comment — to retrieve data that Zendesk already has and already renders correctly for email notifications. Proposed solution:Allow HTML comment placeholders ({{ticket.latest_public_comment_html}}, {{ticket.latest_comment_html}}, etc.) to retain their HTML formatting when used in webhook payloads, rather than converting them to plain text. This could be an opt-in setting per webhook, or a new set of dedicated placeholders for webhook use.This would greatly simplify integrations with third-party ITSM tools (Freshservice, ServiceNow, Jira Service Management) and reduce unnecessary API overhead. Thank you for considering this!
Hello, Currently, customer device information is only surfaced for live chat and messaging conversations. We would greatly appreciate this capability being extended to Email and Web Form channels as well, in order to unify the support experience and improve operational efficiency across all ticket types. We handle a number of sensitive, high-priority projects where having immediate access to a customer's device details is essential to delivering fast and accurate support. Without it, agents are required to manually request this information from customers, which prolongs the conversation, introduces unnecessary back-and-forth, and diverts focus away from the critical issue at hand. This gap affects our team on a daily basis and has a direct impact on resolution times and overall customer satisfaction. Extending device information visibility to Email and Web Form channels would streamline our workflows, reduce friction, and allow agents to focus on resolving cases efficiently from the very first interaction. Our ideal outcome would be for device information to be automatically captured and displayed within the customer context for Email and Web Form channels, consistent with how it currently appears in live chat and messaging.
Hello Zendesk Community,I’m encountering a challenge with our inbound email workflow and would welcome your advice: Current Workflow All customer emails are forwarded into Zendesk via our mail server alias. Zendesk threads replies based on Message‑ID and References/In‑Reply‑To headers, so even if a requester edits the subject line, their reply attaches to the original ticket. Problem We need to know when a requester actually changes the email subject (for example, to introduce a new topic), but Zendesk does not update the ticket’s subject field in that case. Without detecting that header change, agents cannot easily see that the customer meant to start a new conversation—this leads to confusion and delayed follow‑up. Looking For Best practices or existing apps that can parse the incoming email’s Subject header (before Zendesk threading) and flag or warn agents when it differs from the stored ticket.subject. Any sample workflows, triggers, or API‑based solutions that reliably surface “subject‑only” edits as a distinct event or internal note. Thank you in advance for your insights and recommendations!
Hi Everyone,We’ve launched a new Jira integration for Zendesk Support, designed to give you more flexibility, better performance, and a smoother workflow between Zendesk and Jira. Learn more about what’s changed. If you’ve started using the new integration, we’d love to hear from you! What’s working well so far? Is there anything that could be improved? Any features you’re excited about or would like to see added? Your feedback is important and helps us make the integration better for everyone. Please post a comment to this thread with your thoughts, suggestions, or questions. We look forward to hearing about your experience!
Please allow the option for custom Branding in the Unified Navigation feature. At its current state, it is very dull and everything is gray and blending, icons look like they are simply floating in space, there is no contrast or visually pleasing accents. I am sharing comparisons between my current setup and the Unified Navigation EAP in the Sandbox:Support: Admin Center (collapsed menus, no context on menus unless you hover) : Quality Assurance (the worst look in my opinion): WFM (same collapsed menus as Admin Center):Analytics: Separating the products in this post makes it easier to compare, but if you only have the Unified Navigation activated and navigate through the products, you can actually get lost and not know which product you are currently in for a few seconds. I understand the need and concept of unifying the system UI, but this feels a bit too much and there is nothing distinct between the products and removing the branding coloring and only using 2 shades of gray and white is an odd choice.My main request is to please add some colour choices.Thank you
We use Zendesk to manage a large internal service catalog with dozens of request types across multiple departments and have implemented a customized Copenhagen theme for our Help Center. As the number of forms grows (~80+), it becomes increasingly difficult for both agents and end users to navigate and find the correct request form. Currently, there is no sufficient categorization or search functionality in the service catalog, even with theme customization.This leads to users selecting incorrect forms, which results in misrouted tickets, additional manual work for agents, and delays in request processing. It also reduces the effectiveness of structured workflows and automation.This issue occurs daily, especially for new users or employees who are not familiar with the system. They often struggle to locate the correct request type and either submit incorrect requests or contact support directly, increasing the workload on the service desk. Over time, this negatively impacts user experience and operational efficiency.As a workaround, we provide internal instructions and training, and agents manually redirect or correct tickets. While the customized Copenhagen theme allows some UI improvements, it does not fully solve the lack of native categorization and search capabilities. This approach is not scalable and consumes significant time.Ideally, the service catalog should support clear categorization (e.g., by department, service type, or user role) and include a robust search function that allows users to quickly find the correct request form. This would significantly improve usability, reduce errors, and enhance overall service delivery.
We use Zendesk as an internal ITSM platform and have configured a large number of custom ticket forms (~80) to support different service request types across IT departments. However, when agents create tickets from the “support” workspace, they are only able to select default forms such as “Generic Request” and “Incident,” which affects service desk agents who frequently create tickets on behalf of users. This creates a major issue where agents cannot select the correct form, leading to incorrect classification, missing required fields, and broken workflows. As a result, data quality decreases and automation, reporting, and SLA tracking become unreliable. This problem occurs on a daily basis. Many requests come via phone calls or in-person interactions, and agents are required to log tickets manually. Since the correct forms are not available, they either choose incorrect ones or bypass structured data entirely. Over time, this creates inconsistencies in reporting and makes it harder to manage service categories effectively. As a workaround, agents sometimes use the end-user interface to access the correct forms or manually adjust fields after creating the ticket. Both approaches are inefficient and increase the risk of human error. Ideally, agents should have full access to all configured ticket forms directly within the agent workspace, with the ability to search and easily select the appropriate form even when a large number of forms is in use.
I find it very difficult to manage custom attributes and/or metrics. I would love to determine what custom work is being used on which reports so I know: 1) Is it safe to delete it? 2) If I edit it what reports will be effected. Having a page listing all custom attributes and metrics with a list of reports they being used on would great benefit the task of cleaning up unused custom work.
We would like to request an enhancement to Zendesk Explore’s filtering capabilities to allow for more refined filtering based on User Segments, allowing the usage of Organization, tags, and/or email domain.Use Case:In our workflow, we categorize our end-users into Organizations and further differentiate them using User Segments. This segmentation helps us deliver targeted support and understand the needs of distinct customer groups.However, when building reports in Zendesk Explore, we’re currently limited in how we can filter end-user data. Specifically, we’re unable to include or exclude users based on these User Segment attributes. This limitation restricts our ability to generate precise and actionable insights for specific groups of users.Proposed Solution:We request that Zendesk Explore incorporate the ability to:- Allow inclusion or exclusion of specific User Segments as filter criteria in dashboards and queries.Impact:Enhanced filtering would allow teams to:- Tailor reports and dashboards for specific client groups or internal stakeholders.- Analyze support trends by user type or organization.- Improve decision-making by generating more focused and relevant insights.This would provide significantly more flexibility in reporting and better alignment with how Zendesk is used to segment and manage our customer base.
Hi, I would like to see a conditional minimum and maximum character limit for custom fields, e.g. we have a field which can be filled in by an end user, we call it 'Complaint Detail', I would like to add conditions to this to ensure someone write a minimum of 100 characters, maximum 1000. We need data entry to be accurate on forms but at the moment the system allows anything to satisfy a mandatory field, we either get one-word entries such as 'problem', or someone writes an essay. This mostly applies to multi-line fields but could apply to all. The conditional setting needs to be native and shouldn't be difficult to implement. Hope this makes sense?
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
