Skip to main content

Ideas Status Pipeline

Filter by idea status

Filter by product

8662 Ideas

anthony castanoContributor

Native Analytics and Lifecycle Management for Scenario ExecutionsNew Idea

The ProblemCurrently, Scenarios are a "black box" regarding individual agent adoption. As an Admin, I cannot easily see: The Training Gap: Which agents are manually performing 5+ steps that a single Scenario could handle in one click? The Permission Gap: Are agents not using Scenarios because they lack the "Execute Scenario" permission in their custom role? The Adoption Gap: Which teams/groups have successfully adopted automation vs. those still using legacy manual workflows? The Solution (The Request)We are requesting an "Agent Usage" layer within the Scenarios and Analytics modules: "Usage by Agent" Reporting: A native report in Analytics that shows a breakdown of Scenario executions per agent. This allows Admins to identify "Power Users" and those who may need additional enablement. Permission Visibility in Admin View: Within the Scenario list, a "Visibility" or "Availability" column that shows which Agent Roles or Groups currently have the rights to see/execute that specific Scenario. "Attempted but Denied" Logs: An audit log entry for when an agent tries to use a feature they don't have permissions for, helping Admins proactively fix role-access issues. In-Context Training Prompts: (Optional Suggestion) If an agent manually performs a sequence of actions that matches a saved Scenario, a subtle "Did you know?" prompt could suggest the Scenario to them. Business Value Targeted Training: Instead of broad team training, Admins can provide 1-on-1 coaching to agents with low automation usage. Security & Compliance: Easily audit who has the power to trigger complex "Bulk Action" Scenarios. Maximized ROI: Ensures the time spent by Admins building these automations actually translates into time saved by the entire service desk.  Or at the very least could we have an API for this information?

anthony castanoContributor

Native Analytics and Lifecycle Management for Canned ResponsesNew Idea

Currently, managing Canned Responses in Freshservice is a "blind" process. As our service desk grows, we can accumulate hundreds of templates with no way to track accuracy, relevance, or agent adoption. We are currently facing: Knowledge Decay: Old responses remain in the system with no "Last Modified" visibility, leading to agents accidentally sending outdated instructions or broken links. The "Manual Typing" Efficiency Gap: Admins cannot see which agents are ignoring canned responses and manually typing repetitive replies, leading to inconsistent customer experiences and lower productivity. Menu Fatigue: Agents must navigate through "Ghost" responses (unused for months), slowing down their response time. The Solution (The Request)We are requesting a built-in Analytics and Lifecycle Management dashboard. To effectively manage our communication library and team performance, we need:1. Content Lifecycle Data: Last Modified Date & Author: A timestamp and name showing when a response was last edited. Last Used Timestamp: To identify which templates are currently active vs. those that are "dead weight." Usage Tracking: A "Total Uses" counter visible in the Admin list view. 2. Agent Adoption & Audit Data: Usage by Agent Report: A native report showing which agents are using canned responses most frequently and which are not using them at all. Education Identification: Ability to see if certain groups or new hires are under-utilizing specific folders, allowing for targeted training. Sortable Admin List: Ability to sort by Last Modified, Usage Count, or Last Used Date. 3. Automated Hygiene: Bulk Lifecycle Actions: The ability to bulk-archive or delete responses that have a "Last Used" date older than 180 days. Proactive Alerts: Notifications to Admins when a high-use response hasn't been modified in 12+ months to trigger a content review. Business Value Quality Assurance: Ensures customers always receive the most current, branded, and accurate instructions. Targeted Education: Admins can identify agents who need coaching on using the internal toolkit to improve their "Average Response Time." Admin Efficiency: Shifts the audit process from manual "polling" to data-driven decision-making. Onboarding Speed: New agents can rely on a lean, curated library of high-performing responses rather than 500+ confusing options.  At the very least could we have an API for this information?

spencer.barrett
Apprentice
spencer.barrettApprentice

Restrict Email Ticket Creation to Authorized Contacts Only and Prevent Auto-Creation of New Contacts from Incoming Emails - IdeaNew Idea

Detailed DescriptionFreshdesk currently allows tickets to be created via email even when the sender is not an authorized contact. In addition, if a sender does not already exist as a contact, the platform can effectively allow that person to enter the support workflow simply by emailing in. This creates a serious control gap for organizations that need tighter governance over who can access support.A native capability is needed so that:only approved, authorized contacts can create tickets via email unknown or unauthorized senders are blocked before a ticket is created new contacts cannot be created automatically from incoming emails contacts can only be added manually by internal teams or designated administrators support teams have visibility into blocked or rejected attempts for audit and review purposesThis control should ideally work at the account, customer, or organization level, so that support access is limited to a defined list of approved contacts. If an email is received from someone who is not on that list, the system should reject, quarantine, or otherwise prevent the request from entering the ticket workflow.This is important because current workaround options are not sufficient. Domain restrictions are too broad, since many people at the same customer domain may not be authorized to engage support. Automation rules are also reactive, because the email has already generated a ticket before the rule can mark it as spam or delete it. That still creates operational noise and potential risk.The missing control over contact creation makes the problem worse. If users can effectively establish themselves as contacts by simply sending an email, then support access is not truly restricted. For organizations with strict intake requirements, contact creation must be deliberate and controlled by the support provider, not initiated passively by inbound email.Business Use CaseOrganizations need to ensure that only verified, approved customer contacts can submit support requests. They do not want unauthorized individuals to be able to email support, generate tickets, and potentially appear as valid contacts in the system.Without this control:spam tickets can enter the queue and require manual intervention unauthorized users can submit requests that should never reach agents there is a security risk of someone posing as a customer or claiming association with a client agents may spend time validating whether a sender is legitimate before acting support workflows become less secure and less efficient customer access governance cannot be properly enforcedIn addition, many organizations need to ensure that contacts are only added intentionally by internal teams. A customer or third party should not be able to become a recognized contact simply by emailing in. Contact creation should be controlled internally so that support access remains limited to trusted, approved individuals.For many teams, this is both an operational and security requirement. Email-based support intake should only accept requests from authorized contacts, and contact creation should be restricted to internal administrative control.Problem StatementFreshdesk does not currently provide a native way to restrict email ticket creation to authorized contacts only, nor does it prevent new contacts from being introduced through inbound email behavior. As a result, unauthorized users can email support, generate tickets, and create noise, operational risk, and possible security exposure.Requested EnhancementProvide a native control that:allows email ticket creation only from authorized contacts blocks or rejects unauthorized senders before ticket creation prevents automatic creation of new contacts from inbound emails ensures contacts can only be added manually by internal admins provides logging or audit visibility for blocked attemptsImpactThis is critical for preventing spam, reducing manual ticket review, improving support governance, and mitigating the risk of impersonation or unauthorized customer requests entering the support queue.

spencer.barrett
Apprentice
spencer.barrettApprentice

Enable End-User Subscription to Organization Tickets in Freshdesk - Product Enhancement RequestNew Idea

When Freshdesk is configured to allow end users to view all tickets associated with their organization, those users should also have the ability to subscribe to or follow organization tickets from the end-user portal. This would give customers a way to receive updates on tickets they did not personally submit, but that are relevant to their account, team, or business operations.Today, users may be able to see all organization tickets, but they cannot easily stay informed unless they manually check the portal for updates. This creates a gap in communication and account visibility, especially for organizations where multiple stakeholders need awareness of open issues, progress updates, and resolutions.This enhancement would allow end users to subscribe to:all tickets submitted by their organization, or specific existing tickets they want to monitor.Once subscribed, users would receive notifications for meaningful ticket activity such as:new public replies status changes priority updates resolution/closure reopening of tickets other customer-facing updatesThis would create a more collaborative and transparent support experience, similar to the expectation many customers have from platforms like Zendesk.Business Use CaseMany customer accounts operate with multiple stakeholders who need visibility into support activity, not just the original ticket requester. Examples include IT teams, property operations teams, district managers, regional leaders, and shared service groups. In these cases, one person may open the ticket, but several others need to stay informed on progress and outcomes.Allowing end users to subscribe to organization tickets would help customers:stay up to date on all support issues affecting their account avoid repeatedly logging in to manually check ticket status reduce internal back-and-forth to share updates between coworkers improve coordination across teams when multiple people are impacted by the same issue maintain continuity when the original requester is unavailable or leaves the organization reduce duplicate ticket submissions caused by lack of visibility into existing open issuesOverall, this feature would improve customer transparency, collaboration, and efficiency by making it easier for organizations to monitor and respond to support activity across their full account, not just on tickets created by individual users.

Patrick GSkilled Expert

Multilingual support for Journeys forms (initiator form, phase labels, field labels)New Idea

ProblemJourneys forms — including the initiator form, phase names, task labels, and custom field labels — cannot be translated. There is no YAML export, no translation file, and no native multilingual option for any part of the Journey builder. Organizations running Freshservice in multiple languages have no supported way to present Journeys in their users' language.This is a known gap that already existed in the legacy Employee Onboarding/Offboarding module, and it has carried over into Journeys unchanged. It is a significant barrier for any organization that is not English-only.Expected behaviorAdmins should be able to translate, at minimum:Journey name and description Phase names Initiator form field labels, helper text, and dropdown choices Stakeholder form field labels and descriptions Email notifications sent to requesters and stakeholdersIdeally this follows the existing YAML translation pattern used for ticket forms, or provides an inline translation UI in the Journey builder — similar to how the Service Catalog handles translations.Current workaroundThe only option suggested in community threads is injecting jQuery to manipulate DOM labels client-side based on browser language. This is fragile, unsupported, and breaks on any platform update. It is not a viable solution for production environments.ImpactAny organization using Journeys for employee onboarding, offboarding, or cross-department workflows in a bilingual or multilingual environment is affected. This is particularly relevant for organizations in regions with multiple official languages (Canada, Switzerland, Belgium, etc.).

mbutler
Top Contributor ⭐
mbutlerTop Contributor ⭐

Custom Objects : Some ideas for maturing Custom ObjectsNew Idea

I have been working on a few projects lately. I have been using Custom Objects because they are mini-databases that I can use to help with service requests, but I noticed a few issues that make me hesitant to continue using them. Let’s look at a scenario together. Scenario #1: Informing customers of a specific product about upcoming downtimeIn this scenario (which happened IRL) - I have a product that is critical to the Law Enforcement community. I need to inform that community that the product will not be available for approximately 30 minutes. Cool. Here’s the rub though - not all of my customers use said product. So, I don’t want to send it to all my customers in my FreshService instance. I want to send it to a subset of users.I currently have a custom object with a list of customers who are on the new application. However, when I create an announcement, there’s no way to add users from a Custom Object. This brings me to request #1.Request #1 : Allow access to Custom Objects from AnnouncementsMy Custom Object has a property called “AssociatedAgency” which is a lookup field. You can see that my datasource in this instance is “Departments”, but I’m running in MSP mode - so “Departments” really equals “Companies”. This custom object contains a list of companies that are on the new software. In my announcement, if I could say use the AssociatedAgency field and send a notice to every member who is part of the AssociatedAgency, that would fulfill my request.Custom Object DefinitionBut alas, it’s not meant to be. So then, I had a brilliant idea. I would create a contact group with that same list of companies. Anybody in the company would get the announcement because that already exists within the Announcements module….but that lead me to request #2.Request #2 : Create Workflow Events for Custom ObjectsThink about this. I know need to update two different lists any time a new customer comes on board. if I don’t do that - the two will not be in sync. Here’s my thought, what if there were events that existed for Custom Objects.When a row is createdWhen a row is readWhen a row is updatedWhen a row is deletedThink about it for a minute. Think about the new power.A new row is added - Add the company to a requester group via workflow automator (if it existed) or via the APIWhen a row is updated - Modify a contact group or some other part of FreshService - lessening the number of manual steps. The more manual steps there are - the more room for mistakes exists.When a row is deleted - Imagine if a customer stopped using the software. I remove them from one list, but not another. The customer still ends up in the Contact Group because there is no syncing between the two. So, the customer is getting informed about maintenance for a product they don’t even use.These are the kinds of things I think about when I think about maturing a product. We use these products every day and there are little nuanced things like this that could make FS so much better. I can’t be alone in having these requirements. I’m trying to make FreshService our central hub for all things - but doing so requires some additional maturity of the product to make it function better and reduce the need for additional changes.

Steve RohdeApprentice

Add Support for Bulk Tag Management (Tag Export and Tag Import)New Idea

You can view all tags currently in your Freshdesk account from the Tags page in the Admin module; however, there’s no way to export a list of these tags.  Seems like such a glaring omission and such an easy one to remedy,When I asked Freshdesk support about exporting all tags currently in my company’s account, here’s the response I received:You could get the tag data by exporting the entire helpdesk data. Go to Admin -> Account -> Account Details >Export data > click on the Export button on this page, to receive the data. The export of the entire helpdesk data, in XML format, will be sent to your registered agent email address of this account. I tried this.  It took 13 minutes to receive the download link via email and another 1 minute to download the 65 MB ZPI file.  After unzipping, this was what I found:Unfortunately, the export does NOT contain “the entire helpdesk data.” The export includes XML files for...users (aka “contacts”), tickets, companies, groups and solutions...but not for tags.  😕So, what I ended up doing to create my list of tags was to copy each tag one by one from the Tags page in the Admin module and paste to spreadsheet.  A tedious bit of work but at least our FD account has only 41 tags. REQUEST 1 of 2 - TAG EXPORTPlease add export functionality on the Tags page in the Admin module.  Include the following:tag name tag id count of related tickets  count of related contacts count of related solutions date created created byREQUEST 2 of 2 - TAG IMPORTPlease add bulk import functionality to the Tags page in the Admin module that supports the following:create new tags update names of existing tags remove tags

DonglebooApprentice

Granular Survey Response Visibility — Allow Agents to View Only Their Own Survey ResultsNew Idea

Freshservice currently lacks any mechanism to restrict survey response visibility at the agent level. The only location where the actual free‑text responses from a survey can be viewed is the ticket itself. Once an agent has permission to view survey results, the permission applies globally, meaning they can see all survey responses for all tickets, not only the tickets they handled. There is no option to limit survey visibility so that agents can only see feedback associated with their own work.Analytics is not a workaround: the Freshservice Analytics module cannot display actual free‑text survey answers. It only surfaces sentiment scores, not the written customer comments. Therefore, Analytics cannot be used to provide agents a filtered, privacy‑appropriate view of their own survey feedback. Scheduled reports or exports also do not solve the issue because they do not (and cannot) contain the free‑text responses that agents need for coaching and improvement.This creates a significant privacy and compliance gap, especially in countries like Germany, where individual performance and qualitative feedback may not be visible to all staff. Because Freshservice handles survey responses as an all‑or‑nothing permission, organizations must either:Hide survey responses completely (reducing transparency and coaching opportunities), or Expose every agent’s customer feedback to every other agent (violating privacy expectations and local regulations).Requested EnhancementIntroduce granular visibility controls for survey responses, including: Self‑Only Mode: Agents can only view survey responses on tickets they personally handled. Supervisor/Group Mode: Supervisors or group leads can see survey responses for their team only. Admin Mode: Full visibility remains available for designated roles. Optional Analytics Enhancement: Add optional visibility of free‑text response fields into Analytics with role‑based filtering. Reason for ImportanceTeams need a way to give agents access to their own survey feedback without exposing everyone’s performance data to the entire service desk. This aligns with common privacy requirements, GDPR expectations, and internal HR/works council policies.Roadmap InquiryIs there an expected timeline for providing per‑agent or per‑group visibility for survey responses? The current all‑or‑nothing approach prevents compliant, privacy‑safe usage of surveys in many regions.

DonglebooApprentice

Granular Permission Controls for Curated Reports — Limit Visibility to Specific Users/GroupsNew Idea

Dear FS team,  Freshservice currently provides only two permission states for Curated Reports:(1) Full access to all Curated Reports, or (2) No access at all.This global permission model does not allow administrators to define visibility on a per‑report basis, which is a significant limitation for organizations needing stricter data‑privacy controls.According to Freshservice’s documentation on Analytics → Curated Reports, access is currently governed under a single global permission flag (“View Ticket Reports”) tied to the analyst/agent role. Once enabled, the user automatically gains visibility into every curated ticket report in the workspace. There is no mechanism to:Make certain curated reports public for all agents Restrict sensitive curated reports to specific individuals or groups Allow agents to view only their own performance metrics but not team‑wide/cross-team data Apply group‑based or role‑based visibility rules at the report level Limit visibility of reports containing personal performance indicators (critical under EU/Germany regulations)This creates compliance and privacy challenges, especially in Germany, where individual performance data and survey responses are not intended to be visible to all users.Freshservice currently offers scheduled exports as a workaround, but this does not solve the problem:Users receiving scheduled email exports cannot view live dashboard metrics, and the workaround does not prevent visibility into other reports once global access is granted.Requested EnhancementIntroduce granular report‑level access controls for Curated Reports, allowing admins to define:Public reports → visible to all agents Restricted reports → visible only to selected users or groups Private reports → visible only to the creator or specific roles "Self-only" reports → where users see only metrics tied to their own ticket activity (similar to requester-level restrictions in other modules)This would align Curated Reports with more flexible permission models already present in other Freshservice modules (e.g., Requester/Agent group visibility, Service Catalog item restrictions, and CMDB CI permissions).Additional Need (Previous Request Reference)A similar issue exists for Survey Responses, where agents currently cannot be restricted to viewing only their own CSAT results, and Freshservice provides the same all‑or‑nothing access model. This shows a broader need for privacy-aware reporting controls.Roadmap InquiryIs there an expected timeline or official roadmap for implementing granular visibility controls for Curated Reports and Survey Response visibility?This functionality is essential for teams operating under stricter privacy regulations (Germany/EU) and for performance transparency within large IT Service Desk operations, without overexposing data.

vrc.WilliamActive Contributor

Feature Request: Option to Customize or Disable Phone Number Format ValidationNew Idea

You have ## contacts that need your attention.We’ve started receiving the warning message:“You have X contacts that need your attention.”After investigation, we learned that this appears to be caused by the specific phone number formatting we use for our contacts. It seems that the system recently began enforcing a stricter format, possibly to align with phone integration or third-party telephony standards.Current Behavior:Our team does not use any phone integration features. We typically reference the phone number visually from the Contact Information section and dial it manually. The previous formatting was easier to read and understand at a glance. Example of easy-to-read format:(603) 123-4567 Ext. 123 Example of required (system-compliant) format:+6031234567123 While the latter is technically correct for integrations, it is much less human-friendly and harder to read.Proposed Solutions: Allow custom or multiple acceptable number formats — for instance, permit both human-readable and E.164-compliant versions. Provide an admin or user-level setting to disable or suppress this warning when phone integration is not in use. Optionally detect when phone integration is disabled and automatically relax the validation rules. Benefits: Improves readability for teams that manually dial numbers. Reduces unnecessary alerts or warnings. Provides flexibility for different use cases (integrated vs. non-integrated environments).

daren.johnson
Apprentice
daren.johnsonApprentice

Feature requests: Select multiple users from datasource; add more conditions to sub-select All Users dropdownNew Idea

Now that looping exists in workflows, it’s time to put it to good use within Freshservice itself: administrators should have the ability to design a service request where a multi-select dropdown can reference a data source such as All Users.I have multiple service items where my clients want the ability to make access requests for multiple users in a single ticket. Right now, that’s inconvenient at best: it would require setting up a dropdown field for every user, or a textbox field where (say) email addresses would be entered line-by-line or as CSV. The first option provides input validation, but you’re effectively capped by the number of discrete fields you design, while the latter has no input validation.Multi-select dropdowns to data sources solve this elegantly. If I can pick multiple users from All Users, I can have “as many as I need” in a single field, and then I can use loop through the array within WFA to provide the access requested. The data is validated because I can only select valid users, the user information can be immediately accessed through whatever reference the array uses, and those references can be fed through the WFA loop to do the job.*Second, I’m building an account reactivation service request for a client. Currently the only condition options to sub-select All Users in a dropdown are Department and Location. It would be very useful to have the ability to define “Is Deactivated” as one of many additional useful conditions for filtering All Users. Some others I can imagine being useful: Is VIP; Is a member of a group; Title includes; email address includes; Tags includes; and Reporting Manager includes. You could do a lot here!