Please add a cart / basket for the service desk so multiple items can be created with the same ticket.I know you can already add ‘Additional Items’ however that would mean making an entire list of the complete catalog as an additional item for each item, which is just not feasible.
wishing there was a method to loop, or call part of a workflow… e.g. having multiple condition statements that would run in sequence regardless of the previous condition’s result.
If an Incident is associated with a change “change causing this incident” the Incident is not displayed on the Change > Associations > Tickets caused by this change list.
We are running into an issue with asset management due to having 2 workspaces with assets enabled. When selecting Managed by Group in the secondary workspace’s inventory, it brings up the groups from our primary workspace instead.It would be much more useful to have this field pull the groups from the appropriate workspace, like it does if you are an admin on the account.
I like the functionality to integrate teams and the upcoming features of adding the linked teams conversation to the ticket as well. So no information gets lost when agents decide to switch to teams instead of writing notes in the ticket.Though the functionaity to create or post to a channel is not enough. Following this thought you have an incident and a server is not working anymore. This affects multiple teams and could increase to any number of agent groups within the system so they all have to discuss and find the solution asap. There is no teams channel in microsoft teams that contains exactly these agents or agent groups.So my suggestion is to add the ability to create a text chat on top to the channel abilities so that I as the initiator of the chat can add whoever is needed from my microsoft teams organisation to help with the incident. This saves a lot of time cause I dont have to maintain a teams channel or add people to that channel.
We are the top mobile application development company in India having 10+ years of experience in Custom iOS & Android Mobile app development Services. Hire Best App developers from Quytech.
Enable Two-Way Synchronization Between Google Admin Console and Freshservice ChromeOS Device AssetsDescription:Currently, the ChromeOS Device Discovery in Freshservice provides a one-way sync that imports Chromebook asset data from the Google Admin Console into Freshservice. This helps keep our asset inventory up to date, but limits the ability to manage and maintain Chromebook information efficiently across both systems.We are requesting that Freshservice introduce a two-way sync capability, allowing select editable fields to be pushed back from Freshservice to the Google Admin Console.Business Need / Use Case: Our team frequently updates asset information such as: Assigned user Location / department Asset tags Notes / ownership info These fields must also be kept accurate within Google Admin for proper device management, assignment, and auditing. Because the current integration is one-way, any updates made in Freshservice require manual duplication in Google Admin, increasing workload and risk of inconsistent data. A two-way sync would streamline asset lifecycle management and eliminate redundant administrative tasks. Requested Functionality: Two-way data synchronization for key Chromebook fields (e.g., user, asset ID, location, notes). Ability to configure which fields should sync bi-directionally vs. one-way. Sync scheduling options (e.g., real-time, hourly, daily). Full audit logs for changes made via sync to Google Admin. Impact:This enhancement would: Improve data consistency between Freshservice and Google Admin Reduce administrative overhead Streamline IT asset lifecycle management Improve accuracy for audits and reporting Enhance Freshservice’s value as a single source of truth for IT assets Priority: High — affects daily operational efficiency for Chromebook fleets.Optional Add-on:If direct two-way sync is not feasible short-term, an API-based “write-back” option or webhook-based update mechanism would still provide significant value.
Hopefully a simple request. In the monitoring tools, the Alert reopen interval allows for minutes or hours. This is good for most things, however for our use case we’re experiencing unnecessary tickets due to being restricted to a 24 hour reopen interval. Use case below: We’ve setup a monitoring tool with a vendor so that when a ticket alerting us to an issue on their side, the email flows into FS via alerts so that only one person is able to work on a team, auto assignment happens, etc.When new comments are posted, the notifications all flow into the same original incident, however when the ticket is resolved on our side, a day or two later the vendor will automatically email out asking for “customer approval” on the ticket, then again a week later (at this point the emails stop). The same resource is parsed out on each (which is what alerts are grouping under) but the 24 hour restriction means I now have 3 tickets for the issue instead of 1. While training people on the team to wait to close until they render an approval is possible, I think this use case, as well as others, would merit an expansion of the criteria to be able to accept days (max 30?) Unless of course some of you have thoughts on how to get “around” this/shameless upvote plug? @mbutler @Daniel Söderlund @msconfig87 @zachary.king @DanielRuff
In general, we prefer to Default using the System address as the sender for Freshservice emails, replys and comments. However, there are situation where the Agent would prefer to have the email form a ticket or comment sent from their personal (profile) email address. An option to allow the Agent to select the sender’s (system vs the Agents) email for individual messages. Possibly default to system setting but allow user to select their profile address.
Freshdesk’s current Round Robin ticket distribution often results in uneven and inaccurate assignment, which creates workload imbalance across agents and adds unnecessary management overhead.In real-world usage, agents frequently end up with dramatically different ticket counts (for example: Agent A = 5 tickets, Agent B = 1 ticket, Agent C = 0 tickets), even when all agents are actively in the queue. This occurs despite automation rules and consistent queue usage.Proposed ImprovementsRound Robin distribution should account for true agent workload and participation, not just queue order. Specifically, it should track: Agents currently in the queue Number of tickets assigned to each agent per day Exclude tickets that were deleted or merged (these should not count toward distribution) Optional consideration of total active/open tickets per agent (load-based distribution) Reset daily distribution counts at midnight This would ensure assignments are fair, predictable, and aligned with actual work performed.Common Scenarios That Break Distribution Today From day-to-day support operations, these situations consistently disrupt Round Robin accuracy from my testing. Auto-generated email tickets Some systems send unavoidable automated emails (delivery failures, out-of-office replies, etc.). Even when these tickets are immediately auto-deleted via automation, they still appear to affect Round Robin distribution. After-hours ticket intake Tickets received overnight are assigned automatically to agents who remain in the queue. This is intentional to prevent missed assignments, but it skews distribution the following day since those tickets already counted toward Round Robin. Ticket merges When a new ticket is merged into an existing one (for example, when a customer replies incorrectly, creating a new ticket), the merged ticket still appears to count toward assignment totals, even though no new work was created. Queue re-entry behavior When agents leave the queue for lunch and rejoin, they appear to be placed at the “top” of the rotation, receiving the next ticket regardless of how many tickets they’ve already handled that day. Tracking daily assignment counts per agent would make Round Robin significantly more transparent and fair in these scenarios.Bonus / Advanced Options (Optional but Powerful) Load-aware distribution Prefer agents with fewer open tickets when assigning new ones. Resolution-time awareness Very short-lived tickets (e.g., opened and closed within 30–60 seconds) should optionally not count toward Round Robin distribution totals, as they don’t represent meaningful workload. Expected Benefits Fairer ticket distribution across agents Less manual intervention by managers Improved morale and perceived fairness More accurate reporting and workload balancing Better alignment with real-world support workflows
The ability to administer roll assignments for agents directly from the role editing screen would be a good convention to make managing role assignments more streamlined and consistent.When every agent has to be individually assigned roles, this invites inconsistency and misconfiguration, leading overall to more risk. Role/Permissions management should allow standardized assignment. The system would benefit from a way to assign roles in a standardized way
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.
OKSorry, our virus scanner detected that this file isn't safe to download.
OK