Discuss ideas, submit feedback, and track what's next
Help us understand your request
An intake-ready template
OverviewKnowledge Copilot lists knowledge gaps, but these knowledge gaps do not refresh once action has been taken. This makes it cumbersome to continually review and manage knowledge gaps and increases the unlikelihood that we will adopt this feature long-term. What would your ideal solution look like?It would be ideal for knowledge recommendations to either update real-time when actions were taken OR for the team to dismiss recommendations when acted upon. This way, the recommendations data contains only relevant data that the team needs to review.When did this issue last affect you? How often does it happen, and what impact does it have on your work?This is a consistent issue that has affected us each time we use Knowledge Copilot. Coupled with the fact that we cannot filter by the most impactful recommendations, this increases our risk that this feature is not utilized to its full potential, and the highest knowledge gaps are missed.
For Knowledge Copilot, we ideally need the ability to set which roles / groups have access. Currently it requires full admin rights to be able to view or use the Knowledge Copilot. I would like to allow all of our Technical Writers access to the tool, so that it can be collaboratively reviewed and recommendations discussed and acted on, but I do not want to make the full team global admins. Even if it was limited to Knowledge admins, this is still better than having to grant full system admin rights to every user that should have access.
What is your request? Who does it affect in your organization?We would like Knowledge Copilot to be available to users who have Manage Knowledge/Knowledge Admin permissions, without requiring full Support Admin access. This primarily affects colleagues whose role is focused on managing and creating Knowledge content, such as our Customer Education Specialist, but who do not need or should not have access to wider Zendesk administration.What problem would this solve?Currently, accessing Knowledge Copilot requires full Support Admin permissions in addition to Knowledge Admin permissions. This means we have to choose between giving a user significantly more access than their role requires or preventing them from using a Knowledge tool that is directly relevant to their responsibilities.When did this issue last affect you? How often does it happen, and what impact does it have on your work?This issue came up recently when we wanted our Customer Education Specialist to use Knowledge Copilot as part of their role. We expect this to be an ongoing requirement as they continue to manage and develop our Knowledge content. Giving them full Support Admin access would provide permissions over areas of Zendesk that are unrelated to their role and could create unnecessary security and governance concerns. As a result, we are currently unable to give them access to a feature that would be useful in their day-to-day work.Are you using any workarounds?Our current workaround is for the user to continue managing Knowledge without access to Copilot. The alternative would be to give them full Support Admin access, but we do not consider this an appropriate workaround given the additional permissions it provides.What would your ideal solution look like?Ideally, Knowledge Copilot would respect the existing Knowledge Admin/Manage Knowledge permission, allowing users with responsibility for Knowledge to use Copilot without requiring full Support Admin access. This would provide the functionality they need while maintaining appropriate least-privilege access within Zendesk.
We have Master Data Management (MDM) in place, and many of our 'Organisation fields' are populated from this system, so Agents should not make any changes/edits to them. Could there be a way for these fields to be greyed out and uneditable so that Agents could copy/paste data from these fields, but not edit them?
1. What is your request? Who does it affect in your organisation? (2–3 sentences)We would like the ability to create a custom agent role that provides view-only access to Admin Center > AI > Admin Copilot > Recommendations (particularly Macro recommendations) and Admin Center > AI > AI Agents > Automation Potential Report. This would allow agents and operational subject matter experts to review AI-driven recommendations and automation insights without requiring full Zendesk administrator privileges. We are looking to make these insights available to up to 200 agents and 80-90 SMEs while maintaining appropriate access controls and avoiding the need to assign full admin roles.2. What problem would this solve? (1–2 sentences)Currently, these features are only accessible to Zendesk administrators. While administrators have the required permissions to implement changes, they often lack the operational context needed to evaluate recommendations, whereas agents and process experts who have that knowledge cannot access the insights independently.3. When did this issue last affect you? How often does it happen, and what impact does it have on your work? (3–4 sentences)This issue affects us on an ongoing basis whenever we review opportunities to improve macros, automation, and AI-driven support processes. It occurs regularly as part of continuous service improvement activities. Because only administrators can access the recommendations and reports, reviews must be conducted together with an admin, creating additional coordination effort and slowing down assessment and decision-making. This limits the ability of operational teams to proactively identify and prioritize improvement opportunities.4. Are you using any workarounds? If yes, explain briefly. (1–2 sentences)Currently, agents and process experts review the recommendations together with a Zendesk administrator during dedicated sessions. In some cases, screenshots or manually documented findings are shared, but this is inefficient and makes collaboration more difficult.5. What would your ideal solution look like? (1–2 sentences)Ideally, Zendesk would support a custom role that provides view-only access to AI recommendations and automation reports without granting full administrator rights. Alternatively, administrators should be able to export and share these recommendations and reports with non-admin users in a structured and secure format.Additional Business JustificationProviding controlled access to these insights would enable the people with the best understanding of business processes and customer interactions to evaluate improvement opportunities directly, while still maintaining appropriate governance by requiring administrators to approve and implement any changes.
The Zendesk Product Team is looking to speak with customers about how you manage service disruptions, recurring issues, incident response, and underlying problems. We’re especially interested in learning how teams identify and group related incidents, investigate root causes, track fixes or workarounds, and coordinate resolution. Your feedback will help inform future Problem and Incident Management capabilities in Zendesk Employee Service. What’s involved?• 60-minute remote interview• Between September 17th and October 2nd• $100 USD eReward (redeemable at retailers like Amazon) Interested?Sign up for a session via User Interviews.If none of the listed times work, please email me with your availability, and we’ll do our best to accommodate. Contact: Tara Rastogitara.rastogi@zendesk.com Additional InformationParticipation is subject to the Zendesk Privacy Notice, including the California Notice of Financial Incentive, where applicable. Any information shared during research remains subject to the confidentiality obligations in your agreement with Zendesk.By participating in this study and receiving compensation from Zendesk, you affirm that such compensation is authorized in accordance with your organization’s policies. Thank you—I look forward to connecting!
I need to send a message to the client informing them that due to their inactivity, the last message was replied to via email, but I don't have enough data to confirm that the continuous conversation was activated.I tried using the "message status" set to active, but that doesn't guarantee that continuous conversation was activated.
Hello,I would like to request the restoration of a critical feature of the Analytics dashboard. Previously, in the legacy system, filtered reports could be sent to different users or groups on a regular basis, without needing to be refreshed every year, and without providing information that is irrelevant or potentially sensitive. Currently, the “scheduled delivery” system for Analytics provides a full view of historical/ticket information without applying the user's data restrictions assigned to them when the dash is shared to them. I would like for this to be an overt feature with clearly defined rules that do not need to be recreated each year. Preferably assigning a data restriction to each delivery definition.
I don’t understand why Zendesk doesn’t have an option to edit messages sent during a live chat. Your CS team mentioned that it’s for QA purposes, and as someone who has managed QA teams for years, I completely understand the reasoning behind that.However, what we’re asking for is simply the ability to edit a message before the customer has read it, which a lot of other ticketing platforms already allow. You could put a short time limit on edits or only allow editing while the message is still unread.People make spelling and grammar mistakes, especially during fast-paced live chats. Being able to quickly correct an unread message would improve the customer experience without compromising QA, since you could still keep the original message and edit history available for auditing. There are many ways to do this.
I would like to request a feature request, when doing public reply, to have 5-10 minutes delay on the email to be sent to the end customer.In case we want to redact a message so that we have time to do this before the email is sent.
We are in a situation where there are good reasons not to use a full HTML email template.This week, we received reports about suspicious activity concerning agent accounts. Agents received an email containing only the message: "Update your password now to keep your account secure. Go to Security Settings," without any additional context. As a result, employees did not trust this email and reported it as suspicious.The option to customize internal service emails would be very valuable. By doing so, we hope to increase employees' confidence in these types of service emails.The feature request, formulated as a user story, could then be something like this:In Admin → Channels → Email → Email Templates, it should be possible to add a separate email template for internal service emails.
1. Describe the problem or needTicket notification sounds in Agent Workspace can only be fully configured from the Chat agent dashboard, at Settings > Personal > Sounds & notifications (`/chat/agent#personal/sounds_&_notifications`). That page controls sound selection, volume and repeat count for conversation requests, auto-accepted conversations and incoming messages.Within Agent Workspace itself, an agent can only mute notifications temporarily. There is no way to change the sound, adjust the volume, or set repeat behaviour without leaving the workspace and navigating into the Chat dashboard.2. Why the current behaviour is a problemWe don't use Zendesk Chat. Our live channel is Messaging, and our agents have never had a reason to open the Chat dashboard. Sending them there to adjust a notification volume is confusing — it's an unfamiliar interface for a product we don't operate, and there's no discoverable path to it from Agent Workspace.It's also awkward from a change-management perspective. Zendesk has announced that Chat is being removed on 31 January 2028, with dashboard access ending 28 July 2028. Directing agents into a sunsetting product to configure a current Agent Workspace feature is a strange position for both us and Zendesk to be in, and it raises an obvious question about what happens to these settings once the Chat dashboard is gone.Practically, the result is that most agents simply don't adjust their sound settings at all. They either tolerate the default or mute notifications entirely, which defeats the purpose of the feature.3. Ideal solutionSurface sound and notification preferences natively in Agent Workspace, alongside the other personal settings agents already manage there. Specifically:Sound selection, volume and repeat count for ticket and conversation notifications Notification toggles for conversation requests, auto-accepted conversations, new messages and status changes Available to agents on Messaging-only accounts, with no dependency on the Chat dashboardA sensible outcome would be to migrate these settings into the Agent Workspace profile ahead of the Chat removal date, rather than as part of it.4. Business impactWe run Zendesk across four brands with a Messaging-only configuration. Notification sounds are a real productivity lever for our agents — response times depend on them noticing new work — but the settings are effectively inaccessible in day-to-day use. Right now our only option is to document the Chat dashboard URL and walk agents through a product they otherwise never touch.
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)Allow lookup fields to be 1 to many and/or allow users to belong to custom object records What problem do you see this solving? (1-2 sentences) This will allow us to hopefully set up an association between user and custom object records 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)not yet, but this would allow additional customization in workflows Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)not yet What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)Have a way to associate multiple users to a custom object. I truly don't know if this is possible or how it would be, but I would love if the idea were out there.
It appears that the contributor and light agent roles permit view access to custom objects and are not configurable to be otherwise. On the other hand, these permissions are configurable for other licenses. I understand that there are serious limitations to access governance with regard to custom objects (ie macro bypass of permissions on other roles), and I assume that is inherent to the architecture. However, since other roles can have their access configured, it seems like this restriction on modifications is arbitrary. Custom objects could include sensitive data relevant to work done by private groups and should not be accessible to our light agents, contributors, or other members not in the private group. In the same way as ticket access can be customized. To enforce effective user access governance, the custom object permissions should be configurable for light agent and contributor roles in the same way as ticket access can be customized. 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) Custom objects are visible to users that should not have access. While full licenses for agents can have their custom permissions restricted, due to the fixed config of light agents and contributors, admins cannot customize their access to these data assets. What problem do you see this solving? (1-2 sentences) The lack of customization options for light agent and contributor roles impacts data governance and may expose sensitive data. This limits the usability of the custom objects feature altogether. 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 an on-going issue. This impacts the ability for admins to control who access to what data. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences) The only workaround presently available is to not use custom objects to store sensitive data. What would be your ideal solution to this problem? How would it work or function? (1-2 sentences) Unlock the light agent and contributor role customization options to allow admins to restrict/customize access to custom object data. At minimum, for the sake of safest data governance, the default should prevent view access.
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, all time-based triggers are available for Chat, but not for Messaging. This is probably related to the fact that both are different technologies. However, from a user perspective, the web widget looks pretty much like a chat client, and therefore there is an expectation of a real-time chat workflow with messaging.One specific use case that we would like to implement after a handover to a human agent:When a user waits more than 5 minutes without a response from a human agent, we want to send an automatic message to the user, e.g. that we have a created a ticket for the request and that we follow up at a later time. We did not really find a good workaround for this, e.g. making this message dependent on the size of the waiting queue is not the same. With time-based triggers we could achieve a much better communication with the customer in case of longer waiting times.
Ther is currently no native trigger condition that filters by call outcome. (answered versus unanswered) How Zendesk Talk categorises calls:* Abandoned calls are calls where the caller hangs up while waiting in the queue. These create tickets with the subject “Abandoned call from” and can be automatically closed with a trigger.* Non-answered calls are calls that are not picked up by an agent—failed outbound calls, calls missed by an agent, or calls that disconnect before an agent answers. In theory, these should not create tickets.* For known contacts, both answered and unanswered calls use the subject “Call with [Name],” which means there is no reliable subject-based way to distinguish them in a trigger. With Omnichannel routing Zendesk Talk creates a ticket as soon as a call enters the queue, regardless of whether an agent picks it up and whether voicemail is on or off but there is no way for us to auto close these tickets.Its a genuine product gap. There needs to be a way to configure it so you either prevent ticket creation entirely for unanswerd Or there is a distingushing flag/subject so that a trigger can be created to auto close them.
What is Disliked (Current Pain Point)Auto Assist procedures are strictly linear. While procedures can contain backend conditional logic, agents themselves have no mechanism to steer or branch the procedure when human judgment dictates a different path (e.g., choosing whether to troubleshoot or fast-track to RMA). Currently, if an agent wants to deviate from the AI's single suggested path, their only option is to dismiss or bypass Auto Assist completely, losing all automation assistance. The binary [Completed] / [Not completed] buttons in Agent Instructions are the only interactive element available, but they are a poor workaround for explicit workflow choices, mainly because they’re static (hard-coded text) and provide no customizable options beyond the ‘Completed’ / ‘Not Completed’ options.How It Could Be Improved (Proposed UX)Introduce a native Agent Decision Node step within Auto Assist procedures. When a procedure hits a multi-path scenario, Auto Assist should pause and present interactive choice options to the agent in the copilot card (e.g., [Option A: Run Troubleshooting] | [Option B: Skip to RMA]| or even [Option C: Takeover/Escalate]). Clicking an option explicitly instructs Auto Assist which branch to follow, generating the corresponding draft response, macros, or next procedure step based on the agent's active choice.Why This Matters (Business Impact) Preserves Human Agency: Keeps agents empowered to make tactical support decisions without forfeiting AI efficiency. Prevents Workflow Abandonment: Eliminates the need for agents to dismiss Auto Assist and fall back to manual work every time a procedure requires a judgment call. Simplifies Procedure Management: Admins can build single, comprehensive branching procedures rather than creating multiple rigid, single-track procedures or macro hacks. Question for the Product Team & CommunityIs native procedural branching or interactive decision nodes currently on the Auto Assist / Copilot roadmap? I’d love to hear if other teams have found cleaner workarounds for multi-path procedures in the meantime.Thanks for considering this enhancement!
Hi Zendesk team,I would like admins to be able to reorder Unified Agent Statuses, especially to move custom statuses above the default ones. This affects agents, admins, and operations teams because some groups rely more on custom statuses than on the default statuses. When default statuses always appear first, agents may accidentally select the wrong status.This issue happens whenever agents need to change their status during the day, especially when switching between tasks such as lunch, meetings, backoffice work, or training. Since the default statuses are always displayed first, agents may choose one of them instead of the custom status intended for their group. This can cause incorrect availability, routing issues, or confusion for supervisors monitoring agent status. The problem occurs regularly because status changes are part of the daily workflow.We currently rely on agent training and internal documentation to explain which statuses should be used. We have different custom statuses for messaging and email availability, so agents need to be very careful when selecting the correct one. Since custom statuses appear below the default statuses, mistakes can happen, and tickets may be routed to the wrong agents or to agents who should not be receiving that type of work.The ideal solution would be for admins to define the display order of Unified Agent Statuses, including the option to place custom statuses above default statuses. It would be even better if this order could be configured by group or role.
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 teamCurrently, the Messaging Activity Routing feature applies to the entire instance.There is a situation where there is a disagreement between a business that wants to use this feature and a business that does not.If you could break it down so that each group can turn this feature on or off, it would be helpful for operation.
The ProblemWhen manually reviewing or correcting the Intent field on a ticket form, the field currently displays all Intents that have ever been created in the system, including those that have been explicitly deactivated.This behavior is problematic because: Severe Clutter: Our organization has over 60 active Intents, but we have deactivated many default or experimental Intents. These inactive Intents appear in the dropdown, making the list extremely long and visually cluttered. Confusion: Agents or Admins occasionally select the wrong (inactive) Intent, which can break reporting workflows, macros, and triggers. The RequestWe would like the Intent field on the ticket form to only populate with Intents that are set to “Active”. If an Intent is set to “Inactive”, it should be suppressed from the drop down menu. This feature is essential for maintaining the efficiency gained from custom intents: Improved Agent Efficiency: Agents can classify tickets faster by eliminating deprecated options. Data Integrity: Reduces the risk of agents manually applying an inactive Intent, which can lead to reporting errors and automation failures. Scalability: As organizations create, test, and deprecate more Intents, the current behavior becomes unsustainable and unusable.
We recently integrated Zalo into Zendesk as a asynch messaging channel, however in reporting in explore this channel comes under the general “Any Channel”. Has anyone got any ideas/insights into how we could rename this? If there is no solution Zendesk should really look at adding the ability to customise this. As we potentially add more channels via third party apps for channels that are not natively supported this will make reporting more complicated than it needs to be.
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 disable Zendesk password expiry notifications specifically for agents who authenticate through SSO, while retaining these notifications for agents who authenticate using Zendesk username and password. What problem do you see this solving? (1-2 sentences)SSO agents/team members receive password expiry notifications even though they do not use their Zendesk password to access the platform. This creates unnecessary notifications and confusion for users as they believe it is a scam email.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)We recently encountered this when our SSO agents began receiving Zendesk password expiry notifications and raised questions about whether they needed to take action. Since these agents authenticate through SSO, the notifications are not relevant to their normal login process. The issue occurs whenever the configured password expiry interval is reached and can result in unnecessary support questions and thought it was a scam email. We cannot simply disable password authentication because external agents still require it to access Zendesk.Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)There is currently no suitable workaround. Zendesk Support confirmed that password authentication and the associated expiry notifications cannot currently be configured separately for SSO and Zendesk password users.What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)Ideally, Zendesk would allow administrators to configure password expiry notifications based on the user's authentication method. SSO users could be excluded from password expiry notifications while users who authenticate using Zendesk credentials would continue to receive them.
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)Zendesk Explore dashboard filters should dynamically display only values associated with data available in the report. For example, the Requester Organization Name filter currently lists every organization in Zendesk, including organizations that have never submitted a ticket or have no ticket data matching the selected date range. This affects agents, managers, administrators, and reporting users who interact with Explore dashboards.What problem do you see this solving? (1–2 sentences)This would prevent users from selecting filter values that return no results and make dashboards easier and more efficient to navigate. It would also ensure that filter options remain relevant to the current reporting context.When was the last time you were affected by this lack of functionality, or specific tool? What happened? How often does this problem occur and how does this impact your business? (3–4 sentences)This issue occurs whenever users interact with organization and other attribute filters on our Zendesk Explore dashboards. The Requester Organization Name filter displays organizations that have no tickets within the selected date range or no ticket history at all. Users must search through a long list of irrelevant organizations and may select values that produce an empty report. This creates confusion, slows down reporting, and reduces the usability of dashboards intended for operational analysis.Are you currently using a workaround to solve this problem? If yes, please explain. (1–2 sentences)There is currently no effective workaround within Zendesk Explore that makes dashboard filter values dynamically respond to the selected date range and other active filters. Users must manually identify which values are likely to have relevant data.What would be your ideal solution to this problem? How would it work or function? (1–2 sentences)Explore should support data-aware and cascading dashboard filters. Each filter should display only values with records matching the selected date range and all active dashboard filters, and selecting a value in one filter should dynamically restrict the available values in subsequent filters.
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.
![[S_C]RN](https://uploads-us-west-2.insided.com/zendesk2-en/icon/1900207992304.gif){kind=icon}
