Discuss ideas, submit feedback, and track what's next
Help us understand your request
An intake-ready template
Sending this through per the recommendation here. Having no support for HTML or markdown for Dynamic Content drastically reduces the functionality of Dynamic Content. How does this impact us? As we continue to add multi-language support, having no ability to support HTML or markdown when using Dynamic Content in Triggers makes the feature unusable. This increases our trigger count from around 50 to a possible 200 triggers, as we'd need discrete triggers for each language.
First of all: love the addition of callouts to Zendesk Knowledge! We’re currently migrating to Zendesk and our old solutions had them, forcing us to recreate them using custom HTML elements/CSS styling. Having it “Zendesk-native” is a lot better in the long term!Please give a quick overview of your product feature request or feedback and note who in your organization is affected by this issue [ex. agents, admins, customers, etc.] (2-3 sentences)Unfortunately, the content that can be created within callouts is severely limited. Not allowing headlines is not a big deal and not allowing images is probably also for the better. However, not being able to add links within callouts pretty much means we won’t be able to use them for now. What problem do you see this solving? (1-2 sentences)Callouts are often useful as sort of interruptions to the flow. A “hey, this might be important, there’s more info about it here”, for instance. Which is why it’s so frustrating to not be able to add links. 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)Well, it’s a simply lack of support, so it happens pretty much every time we want to create a new article with callouts. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)Yes, we’re using custom HTML that is styled using custom CSS to achieve something that looks very similar to the callouts launched just now. It makes the editing experience worse because you can’t use the native callouts the editor offers, but it supports links (and pretty much all custom styling). What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)Add the ability to add links within callouts. That’s all we need, really :)
Hello, After testing the new functionality for audio comments for messaging and email tickets in our environments, we've identified several concerns that may limit adoption and create customer experience challenges. 1. Audio messages expose the Zendesk domain to end usersWhen agents send audio recordings through messaging channels, customers receive a download link that contains the Zendesk subdomain.Impact: Many organizations intentionally abstract or hide their support platform from customers. Exposing the Zendesk domain:Reveals underlying infrastructure to end users. Creates branding inconsistencies. May raise security or trust concerns in organizations that prefer not to disclose third-party platforms. Can create confusion when customers receive links from an unfamiliar domain.Suggested ImprovementProvide admins with one or more of the following options:Deliver audio files natively within supported messaging channels wherever possible. Allow custom domains for audio delivery links. Provide a configurable CDN or download URL option. Allow attachments to be delivered without exposing the Zendesk tenant URL.2. OGG format creates a significant compatibility issue for iOS usersAudio recordings are delivered in .ogg format.While OGG is natively supported on Android devices, support on iOS remains limited and inconsistent across applications.Impact: This creates an uneven customer experience:Android users can generally access recordings without additional steps. iOS users may need third-party applications to open or play the file. Customers may abandon the interaction rather than installing additional software. Agents have no visibility into whether recipients can actually consume the content being sent.For customer-facing communication, support teams need confidence that recipients can easily access the content regardless of device type.Suggested ImprovementProvide support for more universally compatible formats such as:MP3 M4A AACAlternatively, allow administrators to choose the output format.3. File names cannot be customized, reducing customer trustThe generated audio files use randomized system-generated names.Impact: Customers are increasingly cautious about opening unknown files or links.A randomly generated filename may:Look suspicious. Be interpreted as spam or malware. Reduce open rates. Create confusion regarding the content's legitimacy.This concern becomes even more important in regulated industries where customer trust is critical.Suggested Improvement: Allow administrators to configure a naming convention, such as:Support_Message_{{ticket.id}}Voice_Message_{{brand.name}}Audio_Response_{{agent.name}}Or provide a simple static/customizable filename option.4. No visible reporting or ticket audit events for audio recordingsDuring testing, we were unable to identify clear reporting or audit visibility for audio comments within ticket events/history.Impact: This limits operational oversight and makes it difficult to answer questions such as:Was an audio response sent? How many audio responses are agents sending? Which tickets included audio interactions? Can supervisors audit customer communications? Can reporting teams track adoption and effectiveness?Without visibility in ticket events and analytics, organizations may struggle to govern or measure usage.Suggested Improvement: Expose audio interactions through:Ticket event history. Automatic tags applied on audio recording sent via public/internal comment. Ticket audits. Triggers and automations. Explore datasets and reporting metrics. API-accessible event types.This would allow teams to measure adoption, perform quality assurance reviews, and meet compliance requirements.Overall FeedbackWe like the direction of bringing native audio communication into Agent Workspace and believe it can be a valuable addition for both agents and customers.However, before broad adoption, we would like to see improvements in:Audio delivery that does not expose Zendesk domains. Better cross-platform compatibility, particularly for iOS users. Customizable and customer-friendly file naming. Full audit trail and reporting support.These areas directly impact customer trust, accessibility, compliance, and operational reporting, and could become barriers to adoption for many support organizations.We'd be interested in hearing whether Zendesk plans to address these limitations in future iterations of the feature. Thank you.
Please give a quick overview of your product feature request or feedback and note who in your organization is affected by this issue [ex. agents, admins, customers, etc.] (2-3 sentences)(Forced) enabling of Agentic/Gen3 AI Agents made the bot performance worse (the bot does not recognize some questions that were recognized by Agentic/Gen2), and its analysis more difficult, as it removed the "Unrecognized” denomination, as well as the explanation for the non-recognition of the customer’s question. It is not user-friendly to remove such features when the system itself is not fully developed and working, as those features helped the users to see what to improve in the configuration. This affects the Admins, and consequently the agents and the customers. What problem do you see this solving? (1-2 sentences)The analysis (and the potential improvement) of the bot performance. 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 has happened in July 2026, after switching the bot to Agentic/Gen3. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)The workarounds are multiple, but just patchwork. Not ideal, structured, nor efficient. What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)I’d simply like to have the aforementioned features back. On top of that, while I was trying to send this feedback via ZD chatbot, the bot started the conversation in Italian (the whole ZD page had autonomously switched to Italian). I stated I did not want to talk in Italian, and chose "English" as language, but the bot continued in Italian. The whole experience was frustrating.
Nothing is more infinite than to catch the dream alive and happy with the casts of people no one could imagine.
We have multiple phone lines available for outbound calls, but only want agents to make outbound calls from certain lines. It would be great to assign a default outbound call line to an agent/group, whilst still allowing them to change o another line if it was needed.
Please give a quick overview of your product feature request or feedback and note who in your organization is affected by this issue [ex. agents, admins, customers, etc.] (2-3 sentences)We would like the ability to customize the agent home screen. There currently is the ability for an agent to see tickets in the queue for their groups. This then allows the agent to cherry pick tickets even while using omni channel routing. What problem do you see this solving? (1-2 sentences)This would solve the issue of agents cherry picking tickets from the queue while still being able to search for all tickets. 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 happens on a daily basis when agents view the queue in order to take easier tickets. This then inflates their stats inappropriately. This also causes customers to wait longer as tickets are taken out of order. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)There currently is no work around for this as turning off Agent Home still shows cases in the queue. What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)Ideally you would be able to customize tiles that show on the home page similar to how other pages work. While also being able to remove the ability to see the queue, you could also show specific stats, almost like how dashboards work in analytics.
Please give a quick overview of your product feature request or feedback and note who in your organization is affected by this issue (2-3 sentences)We're requesting that conversation translation be extended to support API/webhook-driven reply channels, along with a send-time visibility flag for agents when a reply bypasses translation. This affects our support agents directly, and indirectly our customers, who may receive replies in the wrong language without the agent realizing it.What problem do you see this solving? (1-2 sentences)It would ensure clients receive translated replies regardless of the channel used to send them, with a visible fallback signal for agents in cases where translation still can't be applied.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)Replies sent through our MS Teams integration via API have repeatedly reached clients untranslated, in English, despite being logged internally as translated. This has recurred across multiple tickets in different languages over the past month. It causes client confusion, repeated back-and-forth asking for their language, and delays in resolving time-sensitive cases (e.g. fund transfers, account verification).Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)Yes, agents now manually translate replies before sending, since our brand/group works exclusively via API and can't use the standard Agent Workspace compose flow where translation applies.What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)Ideally, conversation translation would apply automatically to replies sent via API/webhook channels just as it does in Agent Workspace; as a fallback, a visible flag at send time when translation can't apply, so agents can catch and correct it manually.Related ticket: https://support.zendesk.com/hc/en-us/requests/15023891
Veuillez donner un bref aperçu de votre demande de fonctionnalité ou de vos commentaires concernant le produit et indiquer qui, au sein de votre organisation, est concerné par ce problème [ex. agents, administrateurs, clients, etc.] (2-3 phrases)Dans Analyses, il est impossible de savoir si une mesure calculée ou un attribut calculé standard est utilisé dans un rapport. Quel problème cela permet-il de résoudre selon vous ? (1-2 phrases)Cela permettrait de supprimer toutes les mesures calculés ou attributs calculés standard qui ne sont pas ou plus utilisés. Et ainsi nettoyer la base Analyses, comme par exemple apres un départ d’un collaborateur qui a créé des mesures ou attributs calculés. Quand avez-vous été affecté pour la dernière fois par ce manque de fonctionnalité ou par l'absence d'un outil spécifique ? Que s'est-il passé ? À quelle fréquence ce problème survient-il et quel est son impact sur votre activité ? (3-4 phrases)Je suis confronté tous les jours a cette problématique, sur les diverses instances sur lesquelles je travaille. Utilisez-vous actuellement une solution de contournement pour résoudre ce problème ? (Si oui, veuillez expliquer) (1 à 2 phrases)IL n’y a aucun contournement possible. Donc impossible de supprimer des mesures ou attributs, calculés standards, qui ne seraient pas utilisés Quelle serait la solution idéale à ce problème ? Comment fonctionnerait-elle ? (1 à 2 phrases)A la visualisation ou a la suppression, un message afficherait tous les rapports dans lesquels cette mesure caculé ou cet attribut calculé est présent.
Hello,We are submitting this as a follow-up product feedback item regarding the use of internal Knowledge articles in the Agent Workspace Knowledge panel.In a previous feedback item, Zendesk confirmed that some related functionality already exists: agents may receive a warning when copying or linking an article that the requester does not have access to, and article link actions can be recorded in ticket history.We appreciate that this functionality exists, but we do not believe it fully addresses the governance and data leakage risk we are trying to solve.Current functionalityAs we understand it, the existing behavior helps in cases where:An agent attempts to share or link an article that the requester cannot access. Zendesk displays a warning indicating that the requester does not have access to the content. The link action may be recorded in the ticket history.This is helpful from an awareness perspective, especially when the agent is using article links.Remaining gapThe concern is broader than article linking.Agents can still access internal Knowledge articles directly from the Agent Workspace Knowledge panel while working on a customer ticket. These internal articles may contain sensitive content, such as:Internal procedures. Screenshots from internal or third-party systems. Escalation flows. Operational instructions. Sensitive troubleshooting information. Content intended only for agents or internal teams.Because the Knowledge panel and the public reply composer are available in the same workspace, agents can still manually copy text, partial content, screenshots, images, or other information from an internal article and paste it into a public customer-facing reply.The existing warning does not appear to prevent this scenario, and we do not have an admin-level control to block, restrict, or audit it in a meaningful way.Why the existing functionality is not sufficientThe current functionality appears to focus mainly on article access visibility and article link sharing. However, our concern is about governance of sensitive internal content inside Agent Workspace.The remaining risks are:The warning is passive and can be missed or ignored. Agents can still manually copy internal article content into a public reply. Internal article content can be exposed even if no article link is shared. Admins cannot configure stricter rules for sensitive/internal articles. Admins cannot force internal article content to be inserted only into internal notes. Admins cannot audit whether internal article content was copied into a public comment. Admins cannot apply different controls based on article visibility, section, label, brand, or user segment.This means that while the existing functionality helps with article access awareness, it does not provide sufficient prevention, enforcement, or audit controls for sensitive internal Knowledge content.Requested enhancementWe would like Zendesk to consider additional admin controls for internal or sensitive Knowledge articles used in the Agent Workspace Knowledge panel.Ideally, admins should be able to configure one or more of the following: Prevent internal article content from being inserted into public replies For example: Disable “Copy to conversation” for internal articles. Allow “Copy to conversation” only into internal notes. Prevent restricted article content from being inserted into public comments. Apply these controls based on article visibility, section, label, brand, or user segment. Provide an active confirmation before exposing restricted content For example: Show a blocking confirmation modal if an agent attempts to insert content from an article the requester cannot access. Require the agent to confirm that they understand the content is internal or restricted. Allow admins to configure whether the action should be allowed with confirmation or fully blocked. Improve auditability If prevention is not technically possible in all scenarios, admins should at least have better audit visibility. For example, Zendesk could log: The article used. The ticket ID. The agent. The timestamp. Whether the content was inserted into a public reply or internal note. Whether the requester had access to the article. Whether the agent accepted a warning or confirmation. Support sensitive article governance Admins should be able to define stricter controls for articles that contain sensitive information. For example: Mark articles as sensitive. Restrict copying from sensitive articles. Restrict public insertion from sensitive articles. Show stronger warning language for sensitive content. Track usage of sensitive articles in ticket conversations. Example scenarioAn agent is working on a customer ticket in Agent Workspace. The Knowledge panel suggests or displays an internal article that contains troubleshooting steps and screenshots from an internal system.The requester does not have access to this article.Even if Zendesk warns that the requester cannot access the article link, the agent can still manually copy part of the article content or screenshot and paste it into a public reply. In that case, no article link may be shared, but sensitive internal content can still be exposed to the customer.This is the scenario we need controls for.Business impactInternal Knowledge articles are extremely useful for guiding agents during ticket handling. They allow teams to document complex workflows, improve consistency, and reduce handling time.However, when internal Knowledge content appears next to the public reply composer without stronger governance controls, it creates a practical risk for organizations that use Knowledge articles for sensitive operational guidance.This limits how confidently teams can expand the use of internal Knowledge in Agent Workspace.Expected outcomeWe are not expecting Zendesk to prevent every possible bypass. For example, an agent could still manually retype information or take a screenshot outside the product.However, we would like Zendesk to provide supported controls that reduce accidental exposure and improve governance for internal Knowledge content.The existing warning and ticket history logging are useful, but they do not fully address the remaining risk around copying, inserting, confirming, blocking, and auditing internal article content in public customer replies.We would therefore like this to be considered as a separate enhancement request rather than covered by the existing functionality.Thank you.
Hello Zendesk Community,We are writing to request a crucial feature for better management of our CSAT metrics and internal reporting: the ability to customize the expiration date of the custom CSAT survey link.We appreciate that the expiration period was recently extended to 28 days. However, having this long, fixed period without the option to set our own timeframe is significantly disrupting our internal controls and reporting cycles. 🎯 The Request:We urgently request that Zendesk allow customers to edit and configure the number of days the custom CSAT link remains active after the ticket is solved/closed. 📉 Why the 28-Day Period is Problematic:A 28-day validity period drastically alters our feedback collection and reporting alignment: Reporting Distortion: Our reporting cycles (e.g., weekly, monthly) are much shorter. Responses coming in up to 28 days later skew the metrics for the period when the service interaction actually occurred, making it harder to link performance directly to agent action. Relevance: Feedback is most valuable immediately after service. Extended periods dilute the relevance and accuracy of the customer’s memory of the interaction. Operational Alignment: We need the flexibility to align the CSAT eligibility window with our internal definition of a closed cycle, which is often much shorter than four weeks. In summary, we need to choose the expiration period (e.g., 7 days, 14 days) to ensure our CSAT data is timely, accurate, and aligned with our internal business metrics.Thank you for considering this critical functionality.
We would like to request the ability for administrators to view, access, and manage the native Zendesk CSAT survey URL generated for a ticket before it is sent to the customer.Current LimitationZendesk generates CSAT survey links automatically through placeholders; however, administrators cannot view or retrieve the actual URL associated with a ticket. This limits visibility, auditing, and validation of the survey link before customer communications are sent.Requested EnhancementProvide the ability to:View the CSAT survey URL generated for a ticket before it is sent. Copy and reference the survey URL within the ticket. Expose the survey URL through placeholders, APIs, triggers, automations, and webhooks.Business ValueThis enhancement would improve transparency, troubleshooting, and administrative control over the customer survey experience, while enabling teams to verify and utilize the exact CSAT link associated with each ticket.Expected OutcomeAdministrators should be able to view, copy, and manage the native CSAT survey URL generated for a ticket before it is sent to the customer, providing full visibility and control over the survey process.
Hello Team,We'd like to submit a feature request regarding the Usage Summary page in Admin Center > Account > Usage > Summary.As we evaluate the rollout of Generative Search, effective consumption monitoring has become a priority. The current view presents usage against an annual cap of 1.2M — along with a percentage toward that total — but does not surface monthly consumption in a meaningful way. This makes it difficult to track whether we are on pace with our monthly limits or approaching a threshold that could impact service continuity.What we're requesting:A dedicated, at-a-glance view showing:Current month usage — units consumed so far this billing cycle Remaining monthly cap — units still available for the current month Ideally displayed as both a raw figure and a percentage of the monthly allowanceWhy this matters:Monthly visibility is essential for teams actively managing consumption-sensitive features like Generative Search. Without it, admins are left extrapolating from annual figures — an approach that is imprecise and prone to oversight. A standalone monthly usage indicator would significantly improve our ability to forecast, govern, and respond to consumption trends in real time.We appreciate your consideration and look forward to seeing this addressed in a future update.
We would like to request the ability to customize the button text and title text for cited sources in generative replies (AI Agent Advanced) or, alternatively, an improvement to the default Portuguese (pt-br) translation.Currently, the default translation for cited sources in pt-br uses the word "Origens", which creates a suboptimal UX for end-users in Brazilian Portuguese. Use Case & Pain PointWhen using AI Agent Advanced with generative replies enabled, the bot displays a button linking to the knowledge base articles used as sources.In pt-br, this button and viewer title are labeled as "Origens" (literal translation for "sources"). UX issue: in Portuguese, the word "Origens" sounds unnatural in a customer support chat context and doesn't clearly convey to the end-user that clicking it will open help center articles. Internal feedback: we have received multiple feedback points from internal teams and users stating that the terminology is confusing and non-intuitive. Technical context: looking into the translation keys, the specific parameters affected are: "embeddable_framework.messenger.sources_cited.article_viewer.back_button_aria_label":"Voltar para as origens" "embeddable_framework.messenger.sources_cited.close_button_aria_label":"Fechar origens" "embeddable_framework.messenger.sources_cited.title_and_button":”Origens" Proposed Solutions Customization: allow admins to customize this button text in the AI Agent Admin settings, giving teams full control over their brand tone and local terminology. Localization improvement: if customization is not possible in the short term, changing these translations from "Origens" to a more user-friendly phrase such as "Artigos relacionados" (Related articles) or "Conteúdo relacionado" (Related content) would help. This improvement would benefit all Zendesk customers operating in pt-br using generative replies, significantly improving the end-user experience, clarity, and self-service click-through rates.
Please give a quick overview of your product feature request or feedback and note who in your organization is affected by this issue [ex. agents, admins, customers, etc.] (2-3 sentences) When an email is sent to more than 1 of our support emails, it should create multiple tickets - 1 for each of the support emails that it sent to. We have 4 teams in Zendesk and often all 4 teams have an action to take on an email at the same time. Currently, we have to rely on humans to create duplicate tickets or loop in the right people manually. What problem do you see this solving? (1-2 sentences) This would remove manual work, operational risk from human error, and ensure the right teams are informed of their actions right away - rather than a potential delay from the current assigned team/agent. 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)Daily - Support Tool - We find workarounds for this, but they aren’t always 100% effective. A ticket to Zendesk support was opened here: (#14973370) for a more severe issue we faced which is causing heavy delays for ticket assigning - causing potential late invoicing and late payments. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)Yes, we rely on agents to reassign, clone, or create side conversations to loop in the appropriate team members. What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)It would be great to have a switch that we turn on that would have Zendesk recognize that the email came through to 2 separate support emails, and therefore generates a unique email header for each of those threads. It would also be great to have these automatically connected and parent/children tickets to ensure that we know each team has been informed.
AI code-assist tools like Cursor are great for batch-editing documentation and ensuring consistency across hundreds of articles. But Zendesk's Help Center API makes this nearly impossible.From what I can tell the API only returns rendered HTML, not the source HTML from the WYSIWYG editor. When you fetch an article via API, content blocks get flattened to the rendered HTML. If you update that article back through the API, those content blocks aren't preserved. Why This Breaks Everything Here's a simple example of what I wanted to do: use Cursor to standardize "Frequently Asked Questions" sections across all our docs. Fetch articles, apply consistent formatting, push updates back. I've tested this and Cursor can come up with suggested edits, but I can't push the changes to Zendesk. If I were to do that, every content block in those articles gets converted to static text. Per Zendesk's own documentation:"After updating the article, the links to the content blocks in the Guide editor are replaced with the flat text."So my options are: Manually copy/paste everything between Zendesk and Cursor (defeats the whole point) Use the API and lose all content blocks (not acceptable) Don't use content blocks at all (why even use the value-add features of Zendesk Knowledge?) What Would Actually Help The API needs to expose editor-source HTML with content block placeholders intact. We also need an API to retrieve the content blocks. Let us retrieve and update articles without destroying the features that make Zendesk useful in the first place.Until then, anyone wanting to use modern AI tools for documentation at scale is stuck doing everything manually. We should be able to automate consistency checks and batch improvements without breaking our content. Right now you have to choose: use Zendesk's advanced features, or use modern AI-assisted workflows. You can't have both. For teams managing large documentation sets, that's a significant limitation that doesn't seem to have any good workarounds. If I'm missing something, please let me know. Right now, this has become an urgent issue for us. The productivity gains we're seeing by using code-assist tools like cursor are so great as to force us to look for platforms that support this workflow.
Raising an issue that's going to affect anyone updating Help Center articles programmatically — third-party apps, internal scripts, integrations, and AI agents (including MCP servers).The problemAny update made through the Help Center API causes the article to lose its "new editor" state. The next time someone opens it in Zendesk, the formatting gets reinterpreted through the new editor's strict schema — spacing around images shifts, callouts and HTML blocks get stripped, and the article appears as not-migrated. Editors then have to re-QA and re-fix every article touched by the API.This happens even when the HTML written back is the exact same HTML that was just read from the migrated article.What Zendesk has confirmedAfter a long support escalation, the Knowledge engineering team confirmed:The legacy editor accepted free-form HTML; the new editor uses a strict schema with defined content blocks. The API still only accepts free-form HTML, with no way to signal "new-editor content" or preserve editor state. This is expected behavior in the short and intermediate term.The recently published troubleshooting guide acknowledges the issue but doesn't solve it. There's still no published content-model spec, no compatibility flag, and the suggested HTML-block workaround doesn't reliably work in practice.Why this mattersThe legacy editor is deprecated, every Marketplace app that edits articles hits this, and AI assistants writing back through the API are about to hit it at scale. I've already had a customer cancel because the post-update cleanup made bulk editing unworkable.What would helpA clear timeline for the API redesign. A published content schema for the new editor so integrations can produce compatible HTML today. Treating programmatic access as a first-class requirement — modern support teams rely on apps, automation, and AI agents, all of which run through the API.If your team is hitting this, please comment with your use case and upvote so the Knowledge team has the signal to prioritise it.
Please give a quick overview of your product feature request or feedback and note who in your organization is affected by this issue [ex. agents, admins, customers, etc.] (2-3 sentences)While using thid party integrations such as Salesforce, Organizations may be left with no group assigned when freshly created. This can have a direct negative impact on the workflows if a human error happens, with customers getting their tickets unassigned and unseen for days.Unfortunately there is no way to use Views, Explore, trigger, automations for Organization Groups therefore no real native automation can be implemented.What problem do you see this solving? (1-2 sentences)Groups are one of the most essential and basic components of Ticket ownership and not being able to look at Organization groups in Views or Explore is a real blocker. This is a severe gap which forces us to implement 3 workarounds instead of having a real end-to-end automation.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 created a severe issue for one of our customers. That makes Zendesk look vulnerable to human errors in an unacceptable manner. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)Yes we have implemented several workaround, but those do not fix the problem in the sense that we cannot fully automate Organization Group assignment with a org generated by a Salesforce integration. It's a patch.What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)Support Organization Groups into Automations, triggers, Views and Explore. We can have a default group for Users, so why not for Organizations?
Please give a quick overview of your product feature request or feedback and note who in your organization is affected by this issue [ex. agents, admins, customers, etc.] (2-3 sentences)With the Multi-Conversation functionality in Messaging, users are able to end their chat with the agent and it displays a “ You have ended the conversation” message at the end and labels the conversation as “Ended” from the conversation list. I would like same messaging to appear when an agent ends a chat so the user interface is intuitive. What problem do you see this solving? (1-2 sentences)Right now, when a chat is closed by an agent in a Multi-Conversation setup - it doesn’t display any indication in the widget that the chat has been closed. The reply field disappears which feels like it is very confusing to end-users. 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)Our team is using multi-conversation to improve our chat widget experience. Since chats end abruptly, our users get confused by why they can no longer type back to the agent. We do send messages to the user indicating the closure but it would be nice if it was reflect in the user interface as well. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)Yes, sending messages to the user indicating chat closure. What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)I would like it to include a message when a chat has been ended by agent that says “The Agent has ended the conversation” or something similar. I would also like it if the “Ended” label was added to the chat in the conversation list.
We use Glean to find, summarize, and connect customer data across our apps, including Zendesk Support. We need to include customers' Help Center search results and article views in the dataset. Request: Either make the event data available via API or include it in data sent to Segment.
We recently received a response to our previous feedback request regarding end-user presence detection in Messaging (Improve End-User Presence Detection for Messaging), and we appreciate that Zendesk has introduced support for user presence through the Messaging Session Inactive Reason condition in Ticket Triggers. This is a valuable improvement that enables workflows based on customer presence. However, one of the original requests remains unaddressed: providing a clear distinction between end users who are truly offline and end users who are simply inactive for a period of time.Currently, when using the Messaging Session Inactive Reason condition in triggers, the only available value is "End user inactive or offline." This combines two different customer states into a single condition, preventing administrators from building workflows that react differently depending on whether a customer has left the conversation entirely or is merely idle.This limitation continues to affect our daily Messaging operations. An end user who has closed the widget, navigated away from the page, or otherwise gone offline is fundamentally different from an end user who remains connected but has not interacted for several minutes. Because both scenarios are grouped under the same inactive reason, we cannot accurately tailor follow-up actions, capacity management, routing logic, or automated messaging. This reduces the value of the newly introduced trigger condition and limits our ability to build more intelligent customer engagement workflows.At present, there is no reliable workaround. We can only use the combined "End user inactive or offline" condition, which forces the same automated behavior for both situations regardless of the customer's actual presence status.We would like Zendesk to split the current "End user inactive or offline" value into at least two distinct inactive reasons:End user is offline – the customer is no longer connected or present in the Messaging session. End user is inactive – the customer remains connected but has not interacted for a defined period of time.Providing separate values would allow triggers, automations, reporting, and workflow logic to react appropriately to each state and would offer a much clearer representation of customer presence within Messaging.
Please give a quick overview of your product feature request or feedback and note who in your organization is affected by this issue [ex. agents, admins, customers, etc.] (2-3 sentences)We need the ability to disable or manage the pop-up notifications that appear in Agent Workspace whenever a side conversation is updated. We recently rolled out a ticket escalation process built on side conversations, and our support agents are now constantly interrupted by these pop-ups with no admin option to turn them off. This affects all our support agents day-to-day, and admins who have no controls available to address the complaints. What problem do you see this solving? (1-2 sentences)It would give admins control over notification behaviour in Agent Workspace, allowing teams that make heavy use of side conversations to do so without disrupting agents with unwanted pop-ups. 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 is affecting us daily, every time a side conversation is updated — which since our new escalation process launched is multiple times per hour, per agent. Agents are interrupted mid-task by pop-ups for side conversation updates that don't require their immediate attention, breaking their focus and generating repeated complaints to our admin team. We raised this with Zendesk support and were told there is no option to manage or disable these notifications. The impact is reduced agent productivity and pushback against a process that otherwise works well for us. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)No — Zendesk support confirmed there is no setting or workaround to disable these pop-ups, so agents simply have to dismiss them manually each time!!!! What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)An admin-level setting (or per-agent preference) to disable or configure side conversation update pop-ups in Agent Workspace — ideally with granularity, e.g. suppress pop-ups but keep the notification badge/list, so agents can still see updates without being interrupted.
Following the recent enhancement to the messaging “End Session” functionality (Zendesk announcement link), Zendesk now captures and displays the agent who manually ends a session within the ticket event log. However, this information is currently not available in Zendesk Explore (Analytics). This creates a limitation when reporting on tickets, as there is no corresponding attribute in Explore datasets to identify the agent who ended the session. Additionally, the drill-in functionality does not provide visibility into this data, preventing deeper analysis at ticket level.As a result, it is not possible to track or report on session termination activity per agent, which limits the ability to perform QA, auditing, and performance analysis. We recommend exposing this data as a dedicated attribute in Explore datasets and ensuring it is also available within drill-in, so it can be used effectively for reporting and investigation purposes.
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!
Please give a quick overview of your product feature request or feedback and note who in your organization is affected by this issue [ex. agents, admins, customers, etc.] (2-3 sentences)We would like Zendesk to introduce proactive alerts and health monitoring for the Microsoft Exchange Connector when it is unable to retrieve emails from a connected support mailbox. This primarily affects Zendesk Administrators and support agents, but can also impact customers whose emails may not be converted into Zendesk tickets.What problem do you see this solving? (1-2 sentences)This would allow administrators to identify Exchange Connector failures quickly rather than relying on support teams to notice that emails are missing from Zendesk. It would reduce the risk of customer requests going unnoticed or experiencing delayed responses.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)On 5 August, one of our Exchange-connected support addresses stopped converting emails into Zendesk tickets for approx 4 hours due to Microsoft Graph API connectivity errors. We only identified the issue because the affected support team was also monitoring the underlying mailbox in Outlook and noticed emails were arriving there but not appearing in Zendesk. This type of incident is not frequent; however, we manage multiple brands and some teams rely entirely on Zendesk without monitoring their underlying support mailbox. Without proactive alerting, a similar issue could remain undetected and result in delayed responses to customers.Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)Our current workaround is to periodically monitor the underlying Exchange support mailboxes and compare activity with Zendesk. However, requiring every support team to monitor both Outlook and Zendesk introduces an unnecessary manual process and is not an ideal long-term control.What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)Zendesk should proactively notify designated administrators when an Exchange Connector becomes unhealthy, encounters repeated API/connectivity errors, or has not successfully retrieved emails for a defined period. Ideally, Zendesk would also provide a centralized connector health view showing the last successful email retrieval, current connection status, and recent errors for each Exchange-connected support address.
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.
