Skip to main content

Ideas portal FAQ

Find, vote on and share ideas for Freshworks products. Here is how it works and what happens next.

1. Idea stages and what they mean

Every idea has a status. It shows where the idea is today.

How does an idea move from submitted to delivered?
  1. Submitted
  2. Under review
  3. Planned
  4. In development
  5. Delivered

Not every idea makes it to the end. Some stay open for votes as Future consideration. Others are Closed.

You get an email each time the status of an idea you posted, voted on or subscribed to changes.

What does each status mean?
Submitted
We received the idea. It is open for votes and comments.
Under review
Product is looking at the idea.
Planned
The idea is on the roadmap. We have not started building it yet.
In development
Our teams are building it. We expect to release it within 12 months.
Delivered
The idea is live in the product.
Future consideration
We are not planning it now, but it stays open. Votes help us see if demand grows.
Closed
We are not taking this idea forward. See "Why was my idea closed?" below.
Does Planned mean a release date?

No. Planned means the idea is on the roadmap. Timing can change as priorities change. We update the status when work starts and when the idea ships.

2. The basics: from your idea to our answer

Six questions most people ask before they post.

What is an idea?

An idea is a request for a feature or improvement that is not in the product today.

Something broken? That is a bug. Please contact Support so they can help you.

Should I search before I post?

Yes. If a similar idea exists, vote and comment on it instead of adding a new one. Duplicate ideas split the votes, so no single idea shows how many people want it.

How do I submit an idea?
  1. Search. Choose Submit an idea and type a title. Similar ideas appear. Vote on one if it matches.
  2. Describe. Tell us the task you are trying to do and what gets in your way today.
  3. Add context. Pick the product area and tell us how much this affects your team. Add a screenshot if it helps.
  4. Submit. Your idea shows as Submitted.
How will I hear back?

You get an email when the status of your idea changes. To follow an idea you did not post, subscribe to it.

Why was my idea closed?

An idea can be closed for one of these reasons:

  • Merged. A similar idea exists. Your votes move to it.
  • Bug. It is something to fix, not a new request. Contact Support for help.
  • Retired. It no longer fits the product.
  • Already available. The product can do this today.
  • Not planned. We have no plans to build it.

Closed ideas stay searchable, so you can still read the comments.

3. Find ideas and share your thoughts

The quickest way to make an impact is to back an idea that already exists.

How do I find an existing idea?
  • Use the search bar on the Ideas page. Try two or three keywords.
  • Filter by product, so you only see ideas for the product you use.
  • Filter by status to see what is Planned or In development.
  • Sort by votes to see the most requested ideas first.
How do I vote on an idea?

Open the idea and select the vote button. Voting shows us which ideas matter to you. You need to be signed in to vote.

How do I add a comment?

Open the idea and add your comment. The most useful comments say:

  • What you are trying to do.
  • What stops you today.
  • How you work around it, if you do.

"I agree" helps less than a short example from your own work.

How do I follow an idea?

Select Subscribe on the idea. You get an email when the status changes or when someone replies.

I could not find my idea. What now?

Submit a new one. Use a clear title and describe the problem, not only the solution. Then we can see what you need, even if there is more than one way to solve it.

Have a bug or a question about how a feature works? Contact Support instead.

Ideas Status Pipeline

Filter by idea status

Filter by product

8951 Ideas

pedrohfcApprentice

Lack of SLA Policy visibility in Freshservice reports (with real-world impact and workaround)Submitted

 Today, SLA Policies in Freshservice are configured based on conditional triggers such as Subject, Service Item, Agent Group, and custom fields.However, there is no direct relationship between a Service Catalog Item and a specific SLA Policy unless a condition is explicitly created for that item (for example, using the item name or a unique field).In complex environments like ours, where we have multiple SLA Policies with different conditions, this creates an important challenge:👉 A single catalog item can have tickets associated with different SLA Policies over time👉 In practice, most tickets follow one main SLA Policy, but exceptions exist👉 This leads to inconsistent and imprecise reportingMain LimitationFreshservice does not provide a native field that indicates which SLA Policy was applied to a ticket.Even with the large number of available reporting fields, this information is not exposed — making it difficult to:Accurately track SLA performance per service Analyze compliance based on actual applied SLA Understand how much of the SLA time was consumed at resolution Identify deviations and improvement opportunitiesOur WorkaroundTo address this limitation, we implemented the following solution:✅ Created a custom field: “SLA Policy Name”✅ Built an automation workflow that captures the SLA Policy applied to the ticket and populates this fieldThis allows us to:Extract tickets by SLA Policy in reports Perform analysis combining Service Item + SLA PolicyIssues with the WorkaroundWhile helpful, this approach has important limitations:⚠️ The automation is not 100% reliable — in some cases, the field remains empty⚠️ Historical data is not populated (only works for tickets created after implementation)⚠️ Any failure in the workflow leads to data inconsistency⚠️ It introduces additional maintenance complexityBusiness ImpactWithout a reliable and native way to identify the SLA Policy applied to each ticket, it becomes difficult to perform key analyses, such as:Measuring how much SLA time is typically consumed before resolution Comparing expected vs. actual SLA performance Identifying services with misaligned SLA configurations Driving continuous service improvement initiativesFeature RequestIt would be extremely valuable if Freshservice provided:✅ A native field indicating the SLA Policy applied to the ticket✅ Visibility of SLA breakdown per priority (since time varies based on priority level)✅ Availability of this information in Analytics / reporting layer✅ Preferably with historical traceability (even if SLA changes during ticket lifecycle)Final ThoughtsThis capability is essential for organizations that rely on SLA metrics to drive governance, service quality improvements, and compliance.Today, we are able to partially solve it with custom fields and workflows — but a native solution would significantly improve data reliability and analytical capabilities.

SSF12
Apprentice
SSF12Apprentice

Feature Request: Include Approval and Publication Metadata in Solution Article Version History for IT AuditsSubmitted

1. Background & ContextIn Freshservice, we utilize the approval workflow for knowledge base solution articles. New articles or updates to existing ones must be approved by designated individuals or groups before they go live. This feature works very well and ensures the quality and compliance of our internal and external documentation.2. Problem StatementCurrently, the Version History of a solution article does not provide visibility into the historical approval data of older versions. Within the version history view, it is not possible to see:Who approved a specific, older version of the article.Who actually published that specific version.The system typically only displays the current status or the last editor, missing the detailed audit trail of the approval process for each individual historical version.3. Business Impact & ComplianceThis lack of visibility poses a significant challenge during IT Audits (e.g., ISO 27001, ITIL audits, or SOX compliance).Auditors strictly require seamless proof that published knowledge—especially standard operating procedures (SOPs) for critical infrastructure—has passed the correct approval channels.Currently, reconstructing this data requires tedious manual searching through email notifications, global system logs, or historical ticket workflows.4. Proposed SolutionWe propose enhancing the Solution Article Version History view to include audit-relevant metadata for every version iteration.Suggested UI Improvements:Expanded Table/Detail View: Each listed version in the history should feature additional columns or an expandable details panel."Approved By" Field: Displays the name and timestamp of the agent who granted the approval for that specific version."Published By" Field: Displays the name and timestamp of the agent who published that specific version.Target Visual Structure Example:VersionModified ByModification DateApproved ByApproval DatePublished ByStatusv3 (Current)John Doe2026-06-10Jane Smith2026-06-11John DoePublishedv2 (Archived)Julia Admin2026-04-01IT Manager2026-04-02Julia AdminArchivedv1 (Archived)John Doe2026-01-15Change Advisory2026-01-16John DoeArchived5. Benefits of ImplementationAudit-Readiness: Instant, transparent proof for compliance officers and auditors directly within the article interface.Time Savings: Eliminates hours spent manually reconstructing workflows from global activity logs.Quality Management: Enhances internal accountability and traceability if errors are discovered in older documentation baselines.  1. Background & Context!--tgqphd|[]-->In Freshservice, we utilize the approval workflow for knowledge base solution articles. New articles or updates to existing ones must be approved by designated individuals or groups before they go live. This feature works very well and ensures the quality and compliance of our internal and external documentation.!--tgqphd|[]-->!--tgqphd|[]-->2. Problem Statement!--tgqphd|[]-->Currently, the Version History!--tgqphd|[]--> of a solution article does not provide visibility into the historical approval data of older versions. Within the version history view, it is not possible to see:!--tgqphd|[]-->Who!--tgqphd|[]--> approved a specific, older version of the article.!--tgqphd|[]-->!--tgqphd|[]--> Who!--tgqphd|[]--> actually published that specific version.!--tgqphd|[]-->!--tgqphd|[]-->!--tgqphd|[]--> The system typically only displays the current status or the last editor, missing the detailed audit trail of the approval process for each individual historical version.!--tgqphd|[]-->!--tgqphd|[]-->3. Business Impact & Compliance!--tgqphd|[]-->This lack of visibility poses a significant challenge during IT Audits (e.g., ISO 27001, ITIL audits, or SOX compliance)!--tgqphd|[]-->.!--tgqphd|[]-->Auditors strictly require seamless proof that published knowledge—especially standard operating procedures (SOPs) for critical infrastructure—has passed the correct approval channels.!--tgqphd|[]-->!--tgqphd|[]--> Currently, reconstructing this data requires tedious manual searching through email notifications, global system logs, or historical ticket workflows.!--tgqphd|[]-->!--tgqphd|[]-->!--tgqphd|[]--> !--tgqphd|[]-->4. Proposed Solution!--tgqphd|[]-->We propose enhancing the Solution Article Version History!--tgqphd|[]--> view to include audit-relevant metadata for every version iteration.!--tgqphd|[]-->!--tgqphd|[]-->Suggested UI Improvements:!--tgqphd|[]-->Expanded Table/Detail View:!--tgqphd|[]--> Each listed version in the history should feature additional columns or an expandable details panel.!--tgqphd|[]-->!--tgqphd|[]--> "Approved By" Field:!--tgqphd|[]--> Displays the name and timestamp of the agent who granted the approval for that specific version.!--tgqphd|[]-->!--tgqphd|[]--> "Published By" Field:!--tgqphd|[]--> Displays the name and timestamp of the agent who published that specific version.!--tgqphd|[]-->!--tgqphd|[]-->!--tgqphd|[]--> !--tgqphd|[]-->Target Visual Structure Example:!--tgqphd|[]-->!--tgqphd|[]-->Version!--tgqphd|[]--> Modified By!--tgqphd|[]--> Modification Date!--tgqphd|[]--> Approved By!--tgqphd|[]--> Approval Date!--tgqphd|[]--> Published By!--tgqphd|[]--> Status!--tgqphd|[]--> v3 (Current)!--tgqphd|[]--> John Doe!--tgqphd|[]--> 2026-06-10!--tgqphd|[]--> Jane Smith!--tgqphd|[]--> 2026-06-11!--tgqphd|[]--> John Doe!--tgqphd|[]--> Published!--tgqphd|[]--> v2 (Archived)!--tgqphd|[]--> Julia Admin!--tgqphd|[]--> 2026-04-01!--tgqphd|[]--> IT Manager!--tgqphd|[]--> 2026-04-02!--tgqphd|[]--> Julia Admin!--tgqphd|[]--> Archived!--tgqphd|[]--> v1 (Archived)!--tgqphd|[]--> John Doe!--tgqphd|[]--> 2026-01-15!--tgqphd|[]--> Change Advisory!--tgqphd|[]--> 2026-01-16!--tgqphd|[]--> John Doe!--tgqphd|[]--> Archived!--tgqphd|[]--> !--tgqphd|[[1,0,0,7,null,""]]-->!--tgqphd|[]-->5. Benefits of Implementation!--tgqphd|[]-->Audit-Readiness:!--tgqphd|[]--> Instant, transparent proof for compliance officers and auditors directly within the article interface.!--tgqphd|[]-->!--tgqphd|[]--> Time Savings:!--tgqphd|[]--> Eliminates hours spent manually reconstructing workflows from global activity logs.!--tgqphd|[]-->!--tgqphd|[]--> Quality Management:!--tgqphd|[]--> Enhances internal accountability and traceability if errors are discovered in older documentation baselines.!--tgqphd|[]-->!--tgqphd|[]-->!--tgqphd|[]--> !--tgqphd|[]-->

Service Item / Ticket - Requester View & Agent ViewSubmitted

There should be either a separate tab for required fields agents have to complete, rather than having to add it to the ticket view for the right panel to be updated. This then creates more administration and means you are having to go into the ticket field manager, add the fields and then create rules to base on when those appear.  BUT you cannot ask it to show those fields based on the Service Item so we have created a field called tags that has the form names in them and then when we want to show only certain fields we add the tag in the workflow and say if this tag is visible show these fields.  It makes it way more administration. You should have more autonomy as to what fields show up on the right hand panel based on what form it is and then this should be where the required fields are marked for agents to complete at certain stages. This should be managed in the Service Item itself and be a separate tab section in the Service Item for you to add and remove fields.  OR and be able to add these same fields to the task (which should be in the Service Item for administration too) so you can add custom fields to tasks based on what type of for it is. Not have the same templated task fields for every task. This does not make it clear as to what functions need to be done via a task based on the type of ticket. You should be able to add required fields that need to be completed, prior to the task being completed or it does not progress further.

This ideas board reflects customer feedback and our current thinking, and is provided for informational purposes only. Roadmap decisions, including AI-related capabilities, are influenced by many inputs beyond customer votes, such as technical feasibility, security, compliance, and market conditions. They are subject to change without notice. Idea status labels (such as “Under Review” or “Planned”) do not constitute a commitment, promise, or legal obligation to deliver any feature, functionality, or timeline, and are not part of any agreement with Freshworks. Development and release of any product or feature remain at Freshworks’ sole discretion.