Discuss ideas, submit feedback, and track what's next
Help us understand your request
An intake-ready template
We want our Guide articles to stay fresh and relevant and would like to report on the last date each article was updated so we can make sure to review articles annually at least. Thank you.
With all the changes to the Custom Objects over the last couple of years (placeholders are an AWESOME addition), we are finding that we want to use Custom Objects for a lot more things, but we cannot because we are at our limit for 10 lookup relationship fields on our ticket form. Increasing this limit could open up a world of possibilities for us. Given the increased utility of custom objects, are there any plans to raise the lookup relationship limits so that we can take fuller advantage of these great features?
Currently, team members whose role includes permissions to add, edit, and delete triggers, are able to view autoreply triggers but only see a blank dialog when clicking the “Configure” button under “Configure labels and test autoreply”. i.e. these team members can publish a trigger to send autoreplies but cannot configure the article labels that the autoreply should search. When I previously escalated this (as a suspected bug) in a support request, I was informed that this behavior is intended because that dialog is part of the AI agent configuration, which is restricted to admins only, but that feels like an oversight considering that the entire rest of the autoreply configuration can be made available to other roles. Please solve this.
Zendesk Shortcuts currently cannot be restricted by brand and are available globally across all brands once created. In multi‑brand environments, this limitation prevents administrators and authorized team members from tailoring shortcuts to specific brand contexts and increases the risk of agents using incorrect or brand‑inappropriate shortcuts. We would expect Shortcuts to support brand‑level restrictions, allowing their visibility and availability to be scoped to relevant brands only.
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) Customers like to see details, trends of their ticket to measure quality of service, service level agreements. Customers in many cases will need to report on their support ticket trends within their own organization. What problem do you see this solving? (1-2 sentences) Customers need detailed and historical report on their tickets. They also need to export and download, so they can put those into internal service reports. 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) Right after Go-Live, many of our customers complained because of this missing functionality. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences) Lot of manual effort is required and it is a negative user experience to have our customers request us to prepare various reports. What would be your ideal solution to this problem? How would it work or function? (1-2 sentences) An export tickets button on the Help Center under My Request section. Customer would be able to click and then define the export by filters (range, type, state etc). Then Customers would be able to download/get an e-mail of an excel sheet report.
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 need the ability to turn off auto-reassignment when an agent is offlineWhat problem do you see this solving? (1-2 sentences) In our business the MTTR is significantly higher than in a traditional Contact Center. Therefore we need the tickets to stay assigned on the particular agents for days, even if they are offlineWhen 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 basis and it requires manual reassignmentAre you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)We have increased the log-out time significantly but that does not solve the problem permanently.What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)There should be a toggle in settings to turn on/off auto-reassignment when an agent is offline
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) This feedback concerns a recent announcement about the Copilot AI writing tools.Introducing Copilot AI writing tools for Professional plans and above I don't want this enabled by default. I don't want to enable a feature in my environment that's going to stop working after a limited number of uses. This should be DISABLED by default. What problem do you see this solving? (1-2 sentences) I currently do not have the Copilot addon, so I do not have a way to pre-emptively disable or limit this feature to specific groups ahead of time. The announcement says to go to this article to find instructions, but the instructions can't be followed until the feature is already rolled out to my users. I'm guessing I'll have the option to disable this after the feature is enabled in my instance, but that's not really clear. What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)Don't enable features by default that will break after a limited number of uses. From what I can tell, this is just Grammarly, but only for Zendesk. We already have Grammarly, which works across all applications. Why would I want this? I don't want something like this enabled by default, then break after x number of comments, and then have 240 support agents Slacking me about this error.This message efficiently says “Slack Chris when you see this error”.
Hello, I'd be extremely interested in being able to report on user segments, as we are using these to determine if end-users are customers, partners or internal users. Thanks!
I would like to suggest an option where we could configure the AI agent's name in the email channel when responding to customers. We try to provide a more human-like experience, but this isn't possible when the AI agent responds to an email with the name "System". Changing this name would be essential for a more humanized email service.
Hello team,We have observed that Live Data dashboards in Zendesk Explore do not display data for users whose roles do not have the “All data” permission enabled. This occurs even when users have valid access to Explore, the dashboards are shared with them, and their roles are correctly scoped to specific brands. While the dashboards are accessible, no data is displayed unless “All data” permission is granted.The preferred behavior would be for Live Data dashboards to display real‑time data based on the user’s assigned role and brand membership, without requiring unrestricted data access. This limitation currently restricts real‑time operational visibility for brand‑scoped teams and supervisors, either necessitating broader permissions than required or excluding key users from live reporting. Allowing Live Data dashboards to respect existing brand‑based data‑scoping rules would remove this dependency on “All data” permission and improve governance and usability.
Currently, team members can be added as recipients to scheduled Explore dashboard deliveries only if their assigned role has the “All data” permission enabled under Reporting and analytics.When brand membership access is applied, and roles are configured to allow team members to access data only for the brands and groups they belong to, there is no way to add these users as recipients of scheduled dashboard deliveries unless “All data” access is granted.Current Behavior Users whose role does not include the “All data” permission cannot be selected as recipients for scheduled dashboard deliveries. This restriction applies even when: The user has access to Explore. The dashboard is shared with the user. The user’s role is intentionally scoped to specific brands and groups for data visibility. As a result, brand‑restricted users are excluded from scheduled reporting. Expected BehaviorTeam members should be eligible recipients of scheduled dashboard deliveries based on their role and brand membership, without requiring full “All data” access.Delivered dashboards should automatically respect and enforce each user’s data visibility scope (brands they belong to).Business ImpactThis limitation prevents secure and granular distribution of reporting to stakeholders who require access only to specific brands or operational units. It forces organizations to choose between: Granting broader‑than‑necessary data access (by enabling “All data”), or Relying on manual reporting and distribution processes. Both options negatively impact data governance, scalability, and adherence to the principle of least privilege.Requested EnhancementEnable scheduled Explore dashboard deliveries for users with restricted reporting scopes, ensuring that: Recipient eligibility is not dependent on “All data” access. Delivered content is automatically filtered according to the user’s brand.
Median is a great start as an aggregator, but in some cases rather than knowing what value 50% of tickets fall into, you'd like to know the 80th or 90th percentile (for example, 90% of our tickets are answered within X business hours). This can be approximated with attribute brackets and a result path calculation to see what % of tickets fall into each bracket, but there's no easy way to get the exact percentile value, which can be necessary for the most insightful reporting.
ContextWe operate multiple brands in one instance. End users (members of an organization) want to subscribe to tickets to track activity. Current behaviorIf a user subscribes from Brand A, they also receive notifications for Brand B tickets (same org, different brand). As a workaround, they must create email rules—not ideal. Expected behavior A subscription taken within a brand context should only cover tickets from that brand. No automatic cross-brand notifications unless the user explicitly opts in or an admin sets it. Impact Noise and confusion (irrelevant notifications). Brand identity/context mixing. Lower engagement (unsubscribes, manual filters) and extra support load. Acceptance criteria Subscribing from Brand A results in notifications only for tickets with brand=A.
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) Ability to customize or color code different ticket fields that appear in views. Currently, only ticket status (and SLA marker) has a color, which is visually very helpful. We have multiple forms, and specific fields for each forms, so it would be helpful for our agents to quickly visually identify how tickets are different from each other. What problem do you see this solving? (1-2 sentences) See above. 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)Every day. Our agents are very visual and they are used to the customization abilities from our previous vendor. Our new joiners are especially confused, as they would likely to quickly be able to visually identify an “easier” ticket that they know they can solve. At the moment, there is too much text and very little visuals to help distinguish information. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)No. What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)When creating ticket fields, give the option to choose from a preset of ~10 colors. These colors don't need to be visible on the agent interface on the ticket lefthand side, just the ticket views will do.
We've just integrated Whatsapp into Zendesk for the first time. Our Clients/Agents were already heavily using Whatsapp to communicated and we wanted visibility of this workload in Zendesk. Inbound messaging is working fine, but since the Zendesk integration we are now no longer able to reach out to our clients via Whatsapp. We are having to either email or call them. I understand that outbound messaging via the web widget doesn't make sense, but for whatsapp this really should be an option, just as sending an outbound email to a client is possible, sending an outbound whatsapp to a client should be.
It would be helpful for me if there was a notification sound and/or a notification push when a ticket that has been assigned to me is updated. Thank you for your consideration!
What problem are we trying to solve?When a ticket is escalated to Jira using the new Jira integration, which we had no choice but to switch to due to the deprecation of the previous integration, an automated comment is posted to the Zendesk ticket:"This Ticket has been escalated to Jira {key}"There is currently no way to suppress or disable this message. This is problematic because automated comments trigger webhook activity, and the comment itself pollutes ticket audit logs in ways that interfere with downstream workflows. Additionally, the feature is inconsistently implemented: a comment is posted when a Jira ticket is linked, but no equivalent comment is posted when a Jira ticket is removed. This makes the feature incomplete and we as customers are absorbing the disruption of the notification without receiving the full informational value it could provide nor anyway to turn off the feature. Who is impacted?Customers who: Have migrated to the new Jira integration (we had no choice due to the deprecation of the old integration) Run comment-triggered webhooks Use ticket audit logs for operational purposes such as security monitoring or tag tracking How is the problem handled today?We have implemented a workaround via a Zendesk trigger that explicitly blocks the webhook from firing if this specific wording is found in the comment. However, this workaround introduces two ongoing problems: Audit log noise – In our integration we have flows that review all ticket audits for security purposes and to track tag changes. The escalation comment is being incorrectly flagged during this process, creating code overrides to ignore and review overhead. Latent risk of a feedback loop – The blocking trigger has no self-documenting context. If a future team member removes it without understanding why it exists, the webhook could begin firing on every Jira escalation comment — potentially causing a feedback loop between Zendesk and their external systems. The current workaround is fragile, undiscoverable, and does not address the root cause. What would a better experience look like?A configuration option that allows customers to opt out of the automated escalation comment entirely. This could be a simple checkbox in the Jira integration settings such as Why now?As customers we are forced migrant to the new integration due to the deprecation of the old one.The new integration introduced this behavior without a corresponding opt-out, and in its current state the feature is only half-implemented: it notifies on link but not on removal. The workaround in place is functional but fragile, and the risk of a feedback loop is a live operational concern. What are the potential impacts or benefits? Eliminates audit log noise for customers using automated audit review workflows Removes the risk of accidental feedback loops caused by undocumented trigger workarounds Reduces friction for customers migrating from the legacy Jira integration Low implementation cost relative to the operational risk it mitigates Anything else we should know?After the integration calls POST /api/v2/integrations/jira/{{external_id}}/links, somewhere in the server-side flow there is most likely a PUT /api/v2/tickets/{{ticketId}} that adds the private comment or perhaps via your undocumented GraphQL endpoints, but either way the outcome is the same. What I'm requesting is not rocket science, but a conditional check before that call, gated by a boolean configuration option exposed in the integration settings UI. In practical terms, this is a small, well-scoped change: a config flag on the backend, a corresponding toggle on the frontend, and a conditional check in the existing workflow. The development effort should be modest relative to the operational risk it resolves for affected customers.
These type of pop up notifications happen every time the status of a ticket is updated and have to be cleared out manually. It is distracting for agents and causes excessive, unnecessary clicks. It would be great to have an option to disable these pop ups from occurring in the first place. Thank you!
As our reporting suite continues to expand, we are seeing an increasing need for dashboard usage and viewing statistics to align with our internal governance standards.Access to these metrics is critical for two primary reasons: Portfolio Management: These insights will enable us to perform periodic audits to determine which dashboards remain high-value and which should be retired. Team Engagement: Managers require visibility into user interaction to ensure their teams are consistently monitoring key metrics and staying data-informed. Could you please provide an update on the roadmap for this feature or let us know when we might expect these capabilities to be introduced?
Hi team! Sharing a customer request for consideration. Customer uses webhook triggers to send emails due to security restrictions and needs the latest public ticket comment with full HTML (html_body) so the email renders correctly. At the moment, webhook placeholders return plain/unformatted text, and _html placeholders don’t expose raw HTML when sent via webhooks (as documented). While the customer can pass the ticket or comment ID and fetch html_body via the Tickets API externally, they’re trying to avoid involving external services and would prefer a native Zendesk solution. They attempted a Liquid-based HTML parser within the webhook, which partially works but exceeds webhook size limits. Feature request is to explore whether: A webhook placeholder could expose the raw html_body, or A supported native alternative could allow webhooks to include fully rendered HTML for public comments in the future. Thanks for taking a look.
Uanble to move on after clicking the telephone icon
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 serve a multilingual customer base (English and Chinese), and recently began testing Zendesk Talk’s callback feature during our internal rollout. We discovered that once a customer selects the callback option, a fixed system-generated prompt is played, which cannot be modified, skipped, or localized. This creates confusion for non-English-speaking customers and disrupts the overall call flow.What problem do you see this solving? (1–2 sentences)This request would solve the problem of language inconsistency in the callback experience. It would also allow businesses to control and customize what the caller hears, maintaining a seamless multilingual journey.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 was identified during our internal testing phase while evaluating whether to enable the callback feature for live customers. After a caller presses ‘2’ to request a callback, the system automatically plays the following uneditable English-only prompt:“If you prefer to receive a callback at this number, press 1. If you prefer a callback at a different number, press 2.”Even though our IVR allows customers to choose a language (e.g., Chinese or English) at the start of the call, the system still plays this prompt in only one fixed language — the default language set for that Talk line. Zendesk product support confirmed that this message is not included in the “Callback greeting” or “Callback confirmation greeting” settings found under Admin Center > Talk > Lines > Callback. As a result, we have no way to customize, translate, or skip this message.Are you currently using a workaround to solve this problem? (If yes, please explain) (1–2 sentences)No, there is currently no workaround. The system-generated prompt is mandatory and cannot be controlled through the IVR or callback configuration settings.What would be your ideal solution to this problem? How would it work or function? (1–2 sentences)Ideally, Zendesk should provide the ability to disable or customize this specific prompt, including the ability to enforce callback to the caller’s number only. Longer-term, we suggest treating the callback flow as a configurable IVR branch, so it can follow the same language logic and prompt customization as the rest of the menu.
Goodafternoon, Is it possible in Zendesk Talk to call another agent? So for internal calling for agents?
Hi, it would be great if you could see the audit path taken before the call is actually answered, for instance, we had a call which was waiting for 5 minutes before eventually forwarding to voicemail, each agent has 30 seconds to answer so the call potentially tried to connect to an agent 10 times before finally going to voicemail, we have no way of seeing who it tried before it went to voicemail? On the dashboards, you can see who missed calls, but not which calls they relate to?
Hi there, We’ve run into a serious roadblock. We built a fairly advanced chatbot flow in Zendesk’s bot builder that works perfectly in the Zendesk Live Chat. However, when we connect this same bot to WhatsApp, all steps that use “Ask for details” (to capture info and populate ticket fields) are completely skipped. The bot just jumps ahead to the next step or a default path, ignoring these critical data capture interactions. After weeks of building this specifically for a multi-channel rollout (including WhatsApp), we’ve now learned – only after escalating – that this is a known limitation. According to Zendesk support: Data capture (“Ask for details”) does not work on WhatsApp or other social channels. It’s a legacy limitation that is “expected to be addressed later this year” (though they have no ETA and couldn’t confirm it would even happen in 2025). This is extremely frustrating because: The bot builder UI makes it appear the flows are multi-channel by default, with direct integration options for WhatsApp. No warnings. The whole point for us was automated data collection — now we’d have to degrade back to manual agent input or invest in external custom bots. I’ve raised this with the customer who then asked the product team, I've been said that it will be compatible by the end of the year but I can't I can't get an accurate date. To my knowledge the competition has already figured this out. Maybe a fully compatible bob builder with all the channels before entering the AI frenzy would be wise. A simple chat flow with the ability to capture data and compatible with all messaging apps would work great for us and I'm sure we are not the only ones. We don't need to AI everything because everyone else does. For now, it feels like we’ve hit a huge dead end just before launch. It's quite disappointing.
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.
