Skip to main content

Ideas Status Pipeline

8459 Ideas

gnair
Apprentice
gnairApprentice

Feature Request: Two-Way Sync for Google Admin (ChromeOS/Chromebook) AssetsNew Idea

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.

vrc.WilliamActive Contributor

Improve Round Robin Ticket Distribution Accuracy & FairnessNew Idea

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

Daren
Apprentice
DarenApprentice

Location: management and reporting needsNew Idea

Location management in Freshservice is still a major problem for administrators and customers. While it improved with the ability to use Locations as a Data Source field in tickets and service requests, there’s a lot of work that still needs to be done to make it not agonizing to use in practice.You cannot report on Locations in Analytics, because you can’t report on a data source field. You can report on Requester location, but not on Location itself. There’s no practical provision to close a location. If you close a location, you have two primary options: remove the location from the location list—which removes the Location field information for any Incident or SR ticket that was ever assigned there, and rendering the prospect of reporting on ticket history by Location useless; or hide the location from requesters and agents—which requires one Business Rule for Forms for the Incident form, and one ticket for each and every SR that uses Location as a field. SR BRFs cannot be cloned, so each of those rules must be created and maintained by hand. I’ve done it, and It’s a nightmare! There’s also no documented method to move a location. Say a company uses areas and regions to organize stores within a country instead of (or in addition to) states/provinces. How do you move a location from one area or region to another? If you import a new set of Locations via CSV, does it look for existing locations by name and update the existing set like it does for requesters, or will it just overwrite the current information and disassociate your existing tickets? The KB article has no information on this process. I did just discover that you can move a location by changing the Parent Location field and updating it, but this isn’t documented as far as I can tell, and it should be. Furthermore, if a company is reorganizing its locations en masse, handling this one-by-one by hand will be another nightmare: it doesn’t scale well at all.Feature requests to correct these issues:Allow reporting on data source fields, including Locations. Provide a toggle switch (or some similar function) to hide any specific location from new forms of all types, but still allow it to be visible and reportable in Analytics. Let us just… turn Locations on and off! In one place! Alternatively, provide the option to make a Location-related BRF that can be applied to all SRs. This isn’t as good as a toggle switch because we’re still then responsible for hiding locations across multiple BRFs, but it’s better than what we have now. Provide a useful, non-destructive, and documented method to batch-update existing Locations.Thank you for making such a useful product; implementing these ideas will make an overlooked-yet-critical feature vastly more useful and flexible. I appreciate your time and attention! 😊