Recently active topics

As an agent it would be great if we could add filters to a ticket view to our own specifications and then set that ticket view as the “Default” view we see when signing into freshservice.

The ability to print the available data from an asset is absolutely broken. For a single asset with <50 fields it is showing is 24 pages and almost all of those pages are entirely blank.  We occasionally have to provide audit artifacts for certifications and submitting the data in a csv/excel spreadsheet is less than ideal and can lead to questions about data integrity compared to a PDF printoff. 

We are maturing our Asset Inventory and looking at optimizing our experience for the risk team.  In speaking with them, I realized that the ability to have a separate tab on Assets that has fields list would be huge.  With this idea, we could expose the fields for risk related questions (what kind of data does this house, how much, etc etc) that IT doesnt necessarily “care” about. It would also give better capability so far as being able to print out a copy of the data to PDF for an audit artifact and not have it contain all the additional fields that are related to the specific item such as SLA, Operational state, documentation reference fields, etc etc.

Maybe I am doing this wrong, but a lot of the integrations from the marketplace (and webhooks initiated in the automations) require a users api key. I think this is really poor practice, as a lot of the integrations are using my API key. So if I leave, that API key will no longer be available and all the automations and webhooks will break. Unfortunately there’s no static API key outside of a user granted in the freshdesk system, and I feel like it’s kind of insane to have to pay extra money for an additional user license to have this all not be a SPOF.

I believe this flag what we call in ITSM world is “Needs Attention”, is set when the ticket assigned to you is updated by anybody other than you. That means it will show up in your ticket dashboard as highlighted. And as soon you as an assignee make any changes to this ticket, this flag should be reset to null. And this is how it should work. If it isn’t, it has to be made available. Cheers

The ability to embed images into Service Items would be very useful. We do this to help explain to customers what something may look like in order to gather the correct information. We can do this in the description of tickets and when customer’s log a ticket so why are we unable to do this when creating the forms? The ability to add screenshots of error messages so customer’s know what they are logging the form for or how they may be able to find the information we are asking for instead of giving them a link to a published article.

Hello Team,I’d like to request the addition of emoji support in canned responses within the Helpdesk system.Why This Matters:Emojis are a simple but powerful way to improve communication tone—especially in customer support. Right now, the system doesn’t display emojis correctly (often showing as question marks), which limits our ability to personalize messages or make them more approachable.Benefits of Adding Emoji Support: Improved tone and friendliness in responses, helping us sound more human and less robotic Clarity of intent, especially in short replies (e.g., 👍 for confirmation or ✅ for completion) Stronger customer connection, particularly with churches and teams who appreciate a warm, relational tone Consistency, since many of our communication platforms (email, SMS, chat) already support emojis Even just basic support for standard Unicode emojis would go a long way in making canned responses more expressive and aligned with modern communication standards.Thanks for cons

Hello Freshworks Community,We've been looking for a better way to manage complex ticket forms, especially when dealing with multiple custom fields and sections.We came up with the idea of SR Blinds (Section/Region Blinds) to simplify the visual organization for agents and end-users.What is the SR Blinds Concept?The idea is to allow Admins to group a set of related ticket fields or entire sections together and present them in a way that is easily collapsible like a window blind that can be raised or lowered.Why is this helpful? Cleaner Forms: For tickets with 20+ fields (like onboarding or hardware requests), agents only see the most relevant fields immediately. Less Scrolling: Agents can quickly collapse sections they don't need (e.g., 'Historical Notes' or 'Shipping Details') to focus on the immediate issue. Better UX: It makes the Service Portal less intimidating for end-users, hiding advanced options until they click to "pull the blind."

Hi,We have a multi-workspace setup with quite a few “Business” workspaces, each with their own administrator.As of now, when we configure orchestrator apps to enable automation, e.g for  Entra, the apps are available for non-IT administrators as well, when creating automations in their respective workspaces. There is no way to limit the access based on workspace and/or user role, which opens up for unwanted behaviour and risks.When talking to support they suggested a workaround by not having “local” administrators. But that won’t work for us.I’d like for orchestrator apps to have the possibility to be limited to designated workspaces and/or roles, so that we can control the usage.

At the moment, when you create a field - you cannot update that Data Source after it is created. I can understand if it was a Shared Field and used in multiple forms but if it is a field that is only used in a particular form it makes administration just that bit more complicated. What if the wrong Data Source was selected or a Custom Field was created that was better suited for that field or Freshworks make a product update that was more suited for that field. It cannot be updated and therefore would have to be deleted and replaced with a field that had a slightly different name (then maybe updated to the same name after the previous field was deleted and form saved). Having the ability to update the fields Data Source would make more sense and easier for administrative purposes.

Agents need to be able to be defined by Workspace, so they can be ‘Agents’ in one Workspace and ‘Requesters’ in others. One of our biggest issues with Freshservice is how “Agents” in any workspace are treated as an “Agent” in all other Workspaces. If Agent/Requester status were defined BY WORKSPACE the world would be a better place. I’ve brought this up a few times - the answer is that this is “by design” - but it’s poor design. I have a Global Automation to re-open a ticket if a Requester replies or adds a Public Note to the ticket. However, if someone from the HR Workspace adds a Public Note to an IT ticket, the ticket will not re-open. There is no way for HR to request an IT ticket be re-opened if they aren’t the original requester of the ticket without ‘outside intervention’In the IT Workspace, I’ve tried setting up an Automation to help with this, but there is no way for me to say “If Agent in THIS WORKSPACE vs Agent from OTHER WORKSPACE” in the Automator. If I say to re-open a ti

Hi everyone,We are currently migrating to Freshservice and building several large and complex workflows.During this process, we’ve noticed a major limitation — when different condition branches require the same action, we need to duplicate that action node multiple times. This makes workflows harder to maintain, more error-prone, heavier to load and manage and time-consuming to update when something changes In most modern automation platforms, this is solved with a “Looping” or “Shared Action” capability — allowing multiple conditions to connect to the same action node instead of duplicating it. I understand from support that this feature is planned for mid-2026, but given how impactful it is for real-world workflows, I believe it deserves higher priority.This improvement would simplify workflow design dramatically and help many teams migrating to Freshservice. 💡 Suggestion:Please consider accelerating the release of the “Looping” feature to early 2025 or make it available under Early

In the on-call notification emails, all times are listed in the time zone the shift uses. While understandable, there is no indication of what time zone was used, so users simply get notifications that their shift starts at 1 am, when it’s actually 8 am local time. In this (and all) emails, it would be nice to have a placeholder that would convert a time into the user’s local time zone. For example, the current placeholder oncall_schedule.shift.start_time could have another option like oncall_schedule.shift.start_time_user_timezone that converts the start time from whatever time zone it’s in. This might be helpful for any time placeholder -- on-call is just the one where we noticed it first.

“Relevance” is rarely relevant in search results. Just show me the most recent results first, as that is almost always what I’m looking for.For example, if I search by someone’s unique-to-our-company last name “Jefferson”, the “most relevant” search results are tickets from 2 months ago, 2 months ago, 1 year ago, etc. How come those tickets are more relevant for his name than the ticket he submitted yesterday?This has been suggested twice, 10 and 5 years ago, and both are now closed to voting.Sort ticket search results by Last Modified instead of relevance | Freshworks CommunityDefault Search Results should be by date created | Freshworks Community

It would be a nice QOL feature if Assets had descriptive titles like the Tickets do.For example, when a ticket is open the browser, it shows [#1234] Ticket Subject | Portal NameAssets only show Service Desk : Portal NameSometimes I open multiple Asset records that I’m working with on different tabs. It would be nice to see what tab I have what asset open on easily.

We would prefer to have the ability to hide the "Closed" status in the Status menu from agents as well as remove the "Close" button from the ticket template. We want all agents to set tickets to "Resolved" and not have the option to choose "Closed".In addition, the "Close" button on a ticket's template can take on two meanings. It's current purpose is to close the ticket. As such it should state "Close Ticket".However, for our purposes, we would want the choice to hide the button altogether from agents. If that can't be done, then completely remove it from the template. 

I would love to see the option of adding a time entry included under both Bulk Update and Scenario Automation.As we require time entry before any ticket can be closed, we can’t fully automate ticket handling- the agent must always add time on each ticket individually before they can close the ticket.  There are 2 instances we encounter frequently where this is not ideal:Frequently submitted tickets where we know the entire solution and, ideally, would initiate a scenario automation to categorize, add update, add solution, add time and close the ticket as one action. Responding on outage tickets where we may have a dozen or more people who called in the same issue. We’d like to do a bulk  update to categories, set agent, set solution, send reply and account for time spent rather than processing one at a time.