Product ideas | Community
Skip to main content

Filter by idea status

Filter by product

8849 Ideas

Product Feedback: Suggestion to improve the permission to view audit logs for custom rolesDelivered

Following the introduction of the “View audit logs” permission described in the this announcement, we have identified a concern regarding the effective scope of this permission. When the option is enabled for a team member, the interface also displays the “Manage settings” button, which allows users to modify the “Automatically delete PII” feature.Issue DescriptionThe “View audit logs” permission is expected to provide strictly read‑only access to audit information. However, the presence of the “Manage settings” control extends user capabilities beyond this intended scope, granting access to sensitive administrative actions. This results in an unintended elevation of privileges, as users who should only have visibility into audit data are able to change account‑level settings. Additionally, providing access to the “Automatically delete PII” option under a permission that is meant to be view‑only introduces unnecessary compliance and data‑governance risks. This situation also deviates from established least‑privilege principles, as a permission associated with viewing audit logs should not expose configuration mechanisms that have operational and regulatory implications.Suggested ImprovementWe recommend that Zendesk remove or hide the “Manage settings” button for users who are assigned only the “View audit logs” permission. This control, and the ability to enable “Automatically delete PII”, should be restricted exclusively to users with appropriate administrative rights. Ensuring that “View audit logs” remains strictly read‑only would provide clearer permission boundaries and prevent unintended access to sensitive settings.Impact and BenefitsImplementing this refinement would strengthen account security, support compliance obligations, and reduce the risk of unauthorized or accidental changes to data‑retention configurations. It would also ensure greater clarity in how permissions are applied, resulting in a permission model that more accurately reflects industry standards and customer expectations.

Product Feedback: Mandatory Comment Requirement and Hidden Additional Comment Field When Suspending a PlayerUnder Review

Hi team,We would like to provide feedback on the suspension flow for players, specifically regarding comment requirements and UI visibility.We strongly support keeping the comment mandatory when suspending a player. Suspensions are high-impact actions that require accountability, auditability, and clear justification. Mandatory comments are essential for ensuring that decisions are documented consistently and responsibly.However, the current implementation creates a usability issue:the option to leave an additional comment is not clearly visible or discoverable in the UI Reduced audit and compliance value: In reviews, disputes, or regulatory audits, missing contextual details can weaken the justification for a suspension and increase operational risk.Inconsistent internal understanding: Other teams reviewing the case later (QA, Risk, Compliance, Support) may lack the full reasoning behind the action, leading to rework or misinterpretation.Training and onboarding challenges: New agents may not realize that an additional comment option exists at all, resulting in uneven documentation quality across teams. Suggested improvements: Keep the mandatory comment requirement in place for suspensions. Make the additional comment field clearly visible and intuitive during the suspension flow. Maintaining mandatory comments while improving visibility and clarity would significantly enhance data quality, accountability, and confidence when taking critical actions such as player suspensions.

Allow Messaging Web Widget launcher position to be set dynamically via JavaScript / APIIdea Submitted

We would like to request support for dynamically setting the Messaging Web Widget launcher position (bottom-left vs bottom-right) via JavaScript and/or API, rather than only through a global Admin Center setting.Current limitation Launcher position can only be configured globally in Admin Center. There is no supported way to change left/right positioning per page via code. Workarounds (multiple widget instances, custom launcher, embedded mode) add operational and maintenance overhead. Use case On certain pages, the default bottom-right launcher interferes with existing UI elements (e.g., floating CTAs, forms, or consent components). On other pages, bottom-right is the preferred placement. We want a single widget configuration that can adapt based on page context. Requested capabilityOne of the following (any would be sufficient): A JavaScript API option, e.g.zE('messenger:set', 'launcher.position', 'bottom-left') A page-level override parameter in the widget configuration Support for dynamically updating the launcher position at runtime Why this matters Reduces the need for duplicate widget configurations Avoids custom launcher implementations for a simple layout concern Aligns with modern SPA / component-based websites where layout varies by route Improves developer experience without impacting non-technical customers Current workarounds (not ideal) Maintaining multiple Messaging Web Widgets with identical configs Building and maintaining a custom launcher Switching to embedded mode solely for positioning control This would be a small but high-impact improvement for teams with complex or responsive layouts.

CoPilot Feature Request: Restrict Procedures to ticket formsIdea Submitted

Please give a quick overview of your product feature request or feedback and note who in your org is affected by this issue [ex. agents, admins, customers, etc.].We are a global software company with a product portfolio consisting of more than 10 different product families. While these products operate within the same overall domain, they require distinct support approaches.Our customers typically use a combination of multiple product families, which is why we provide support for all of them within a single Zendesk brand. In the current setup, Zendesk Procedures which were created by us specific for product family A are currently used everywhere in a Zendesk brand, means also used for product families B, C, D, etc., which leads to confusion and reduced efficiency for our support teams. Since the products differ significantly in terms of troubleshooting and processes, these crosswise applied Procedures create unnecessary noise and increase the risk of incorrect handling. At the moment, Procedures can only be restricted at the Zendesk brand level. Our feature request is to allow Zendesk Procedures to be restricted by ticket forms and by support groups. This would enable us to provide more targeted, product-specific guidance and improve efficiency and accuracy for our agents.  What problem do you see this solving?As intended, we would like to use Zendesk Procedures to provide agents with clear instructions for action, thereby increasing agent efficiency and customer satisfaction by providing customers with faster and higher-quality assistance. 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?Unfortunately, our tests to this point have shown that we cannot activate Zendesk Procedures with the current implementation because we cannot ensure that they will only be used for the product family for which they were created.Currently, Zendesk procedures distract agents significantly more and even reduce efficiency rather than increasing it. Are you currently using a workaround to solve this problem?We are currently unaware of any workaround and have removed Zendesk Procedures from the configuration. What would be your ideal solution to this problem? How would it work or function?Zendesk Procedures should be limited not only to a Zendesk brand, but also to ticket forms and support groups.

Feature Request: Reordering of System Fields in User Profiles, Tickets, and OrganizationsAccepted

In Zendesk Support, the system fields in user profiles, tickets, and organizations have a fixed order. This can cause some inconvenience for agents, especially when there are important system fields that are located far down the page and others that are not interacted with at all. We propose a feature that allows the reordering of system fields in user profiles, tickets, and organizations. This would provide greater flexibility in customizing the layout and improve the user experience for agents.Use-case example:Our agents often need to link the organization to the user and access specific ticket fields when handling tickets. However, these fields are system fields that are located far down the page in the respective layouts. As a result, our agents sometimes overlook these fields. If we could reorder the system fields, we could move these important fields to a more prominent position, reducing the likelihood of this oversight.Benefits: Improved user experience: Agents can customize the layout of user profiles, tickets, and organizations to suit their workflow. Increased efficiency: Important fields can be placed in more prominent positions, reducing the likelihood of oversights. Greater flexibility: Zendesk Support can be more effectively tailored to meet the unique needs of each organization. We believe that this feature would be a valuable addition to Zendesk Support and would benefit many organizations. Thank you for considering our request.

Export customer ticket functionality on the HelpCenter under My RequestsIdea Submitted

Please give a quick overview of your product feature request or feedback and note who in your org is affected by this issue [ex. agents, admins, customers, etc.]. (2-3 sentences) 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.