Share product ideas and upvotes with our product team
Hi team, It would be great to have an option to disable smart replies or at the bear minimum select the reply that is going to be shown, it’s intrusive and annoying.The replies shown do not even make sense to the given cases. Thanks.
This idea is to create a version history for workflows.When working on workflows, it would be great to have a version history. This is useful when the need comes to revert changes. Also, a version history helps tracking changes made overtime.When testing workflows and making constant changes for testing purpose, having to manually redo-undo isn’t optimal. Being able to restore/revert to a previous version of a workflow would be much easier.
ProblemIntercom currently has no way to auto-generate a unique, per-conversation or per-ticket URL and insert it dynamically into a Workflow message. When a Workflow sends a customer-facing message, there is no variable available that resolves to a direct link for that specific conversation or ticket.The Customer Portal URL variable exists in macros and saved replies, but it is not available in Workflow message steps. More broadly, there is no native mechanism for a Workflow to construct or reference a unique URL for the conversation it is acting on — regardless of whether a Customer Portal is enabled. Use CaseWhen a Workflow sends an auto-close reminder or a follow-up nudge to a customer, the message has no way to include a direct link back to the specific ticket or conversation. The customer must log into the portal independently or locate a previously received notification. A dynamically generated link in the message itself would remove that friction entirely. Requested FeatureA native Workflow variable — for example, {{conversation.url}} or {{ticket.portal_url}} — that resolves at send time to the unique URL for the conversation or ticket the Workflow is acting on. This would allow any Workflow message step to include a direct, per-record link without requiring API customization or pre-stored attributes. Current WorkaroundThe only available alternatives are: storing a pre-generated URL in a custom conversation attribute via the API and inserting that attribute into the Workflow message, or directing customers to the general Customer Portal home page rather than their specific record. Both require significant custom engineering and are not practical at scale. Business Impact- Any Workflow message that touches a customer about an open case could include a single-click path back to that specific record.- Eliminates a common gap for auto-close reminders, ticket creation confirmations, and follow-up sequences where customers lose context between messages.- Removes the need for API-based workarounds to achieve basic deep-linking behavior in outbound Workflow communications.
Inbox filters were showing at the top of the page but that changed with a recent update. Each search requires that I select which filters I want. The filters should remain at the top so I can select options from the drop downs. Another fix to this change could be to allow us to choose preselected filters that always show (similar to reporting or filtering contact lists). Reps need to be able to search quickly but this updated search change slows down their ability to quickly find information. Please revert to the previous version.
One thing we’ve been exploring recently is using Linear to manage the issues we identify with Fin.Assigning an owner, tracking actions and status, and keeping a record of how each issue was resolved. Given that Intercom is increasingly bringing other tools and workflows into the platform, such as Releases, I think it would be really useful to have something similar natively for Fin.For example, being able to flag an issue, create a card for it, with an owner, notes/actions and a status. It could then be moved through different stages as it’s being worked on, and ideally linked back to the conversations affected.If something like this existed within Intercom, it would be perfect and would keep the whole identify → fix → measure feedback loop in one place.
Currently there is no option to filter reporting by time when a conversation started.In this example, I’mm looking to understand reporting metrics for my European Support Team vs my North American Support Team.I understand the distribution charts that are available to see high level when conversations came in, but this doesn’t allow for deeper analyzation of statistics like CX score, replies sent, CSAT score, conversations by channel and many more metrics for a given time period like desired.This information is invaluable and since Intercom already has the data point for when a conversation begins, should be a no brainer to allow users to use this data to build reports and gain deeper insights into our conversational data.
Right now, the only workflow trigger related to ticket assignment is “If teammate changes the conversation team assignment.” However, this trigger only works when the team assignment changes on a conversation. It does not trigger when a conversation is assigned directly to a specific teammate. We’d like to request a new Workflow trigger that fires when a conversation or ticket is assigned to a specific teammate, rather than only when it is assigned to a team.Why we need this: Conversations may initially be handled by Fin or remain in an inbox before being assigned to a teammate. If an existing customer reopens an old ticket, the teammate best suited to handle it may also be different, so the ticket may need to be reassigned. When a ticket is assigned to a teammate, we need Intercom to automatically apply that individual’s SLA via a Workflow, but this isn’t currently possible. Our teammates work across different time zones, so their SLA requirements vary. The SLA therefore needs to be based on who the ticket is assigned to, rather than which team it is assigned to.As our teams grow, it’s unrealistic to expect the person assigning a ticket to know which team to select or which SLA applies to each teammate. The teammate assignment itself should determine the correct SLA.Ideally, the workflow would allow us to set a condition such as:“When a conversation/ticket is assigned to [specific teammate] → apply [that teammate’s SLA].”This would allow us to automatically apply the correct individual SLA at the moment of assignment, without requiring the person making the assignment to manually select the appropriate team or understand each teammate’s working hours/time zone.In short, we need teammate assignment—not team assignment—to be available as a Workflow trigger.
Many users are frustrated with only being able to search on full words instead of partial or wild card searches. For example a search for “mini” produced zero results so the user must type “minimed” to find any tickets associated with that company or project. This proves especially frustrating where users cannot search on a partial name when spelling may be an issue.
ProblemArticles in Knowledge currently support only two states: Live and Draft. There's no state for content that is retired but not deleted — old articles we no longer want live, but might need to reinstate later (e.g., seasonal content, deprecated-then-reintroduced features, content pending a compliance/legal review, or articles kept for historical reference).Right now the only way to handle this is to leave the article as Draft, which is the wrong tool for the job:Draft conflates two unrelated things. Draft is meant to represent work in progress toward publishing — a staged revision or a not-yet-finished article. Using it to mean retired content pollutes the Drafts list with old, dead articles, making it harder for writers to find their actual in-progress work. No way to distinguish "about to be published" from "parked indefinitely." There's no filter, or view that separates a draft that's one edit away from going live from one that's been sitting untouched for two years because we don't want to delete it outright. Search/reporting noise. Draft articles still show up in internal article-management views and counts (total articles, articles by collection, etc.) alongside real drafts, making it harder to audit what's actually being worked on vs. what's just parked. Reversibility isn't explicit. Deleting an article is intentionally destructive; draft doesn't communicate that this content was deliberately taken down with intent to possibly restore it. There's no clear "why is this here" signal for teammates who encounter it later.Proposed solutionAdd a third article state — Archived — alongside Live and Draft:Behavior: Archived articles are automatically unpublished (removed from the Help Center, search, and Fin/Copilot indexing) and excluded from the default Drafts view. Reversible: A one-click "Restore" or "Unarchive" action returns the article to Draft (not directly back to Live, to force a review step before republishing). Distinct list/filter: A separate "Archived" tab or filter in Knowledge, so archived content doesn't clutter the main article list, draft list, or collection counts. Retains full content and version history: unlike deletion, nothing is lost — title, body, translations, tags, and past versions stay intact. Metadata on archive: capture who archived it and when (and ideally an optional reason/note field), for audit purposes. Bulk action support: ability to archive/restore multiple articles at once, since this is often a cleanup exercise across dozens of old articles. API/webhook parity: expose the archived state via the Articles API (state: archived) and via webhooks, so it can be scripted/audited, not just a UI toggle.Why this mattersContent teams need a middle ground between "live" and "gone forever." Deletion is too destructive for content that has re-use value; draft is semantically wrong and creates workflow confusion. An explicit archive state solves both problems with minimal added complexity, and mirrors patterns already common in other CMS/knowledge tools (Notion, Confluence, Zendesk Guide all support some form of archive distinct from draft).
Right now, data connectors can only write and be mapped to people or conversation attributes easily. To write to company attributes, you basically have to have 2 data connectors assigning data on the contact and then prefilling a request to the company with that information. This idea requests that we can map data in the data connector setup directly to the company.
We need our individuals to add custom email signatures (or add custom dynamic fields to the company-wide signature). Our team needs to display their unique calendar link, PTO, work shifts.
Our workflow is setup so that Fin’s initial response begins with an introductory message (something like “Hi, I’m Fin Support’s AI Agent….you can ask to talk to the team at anytime.” Currently this message is also sent when a ticket requires immediate escalation (e.g. inquiry indicates a deadline within the next Xhrs) followed by escalation messaging indicating the ticket is being routed to the team. It sounds odd and is aggrevating for customers to receive two separate ticket updates, one with simply an intro saying Hi, I’m Fin Support’s AI Agent….you can ask to talk to the team at anytime, immediately followed by “I’ve routed you to the team, help is on the way...”. It has been suggested to remove the generic intro message however this is not viable, in the majority of tickets that are not escalated customer need to know they are communicating with an AI Agent and that they can request to get routed to the team. Prior to the the last few weeks Fin used to validate escalations before sending the intro message so customers immediately received the “I’ve routed you to the team, help is on the way...” immeidately, no other genenric intro message.
Problem to Solve:The inbox is the most efficient way to search for conversations and tickets within Intercom, but users with “Lite Seats” don’t have the capability for some reason. Request:Can you add the ability for users with a lite seat to be able to view conversations, inboxes, etc just like everyone else, just not have the ability to respond to customers, and still solely have the view only option?
This synchronization looks very neat: https://www.intercom.com/help/en/articles/15943800-sync-content-from-githubUnfortunately, it lacks support for multilingual content, which is a significant drawback.
Currently, when Notion content is synced to Intercom, the articles are view‑only and can’t be published to the public Help Center. This prevents teams like us that use Notion as their source of truth from publishing those articles directly to customers.We currently have to manually copy articles from Notion, paste it to Intercom, fix the formatting and then publish it.It also means, when we have to make any changes or update the articles, first we have to update the article on Notion, then copy the changes content, edit the individual article in intercom, paste the new content, fix the formatting and then publish it.It would be very valuable if synced Notion articles could be published to the Help Center while still being managed in Notion, so updates continue to sync automatically without manual copying.
We should be able to change the font, font size, font color for texts within an article.Different font sizes and different accent of color helps to better differentiate the texts with various headings, and decrease the cognitive load for the users.Additionally the inline code formatting looks exceptionally bad on the help center, can we fix that as well?
Currently, subcollections inside a parent collection are always placed below articles, even though the interface supports drag‑and‑drop reordering. This creates a confusing experience where the UI suggests flexible ordering, but the system still locks subcollections to the bottom.It would be much more flexible if subcollections could be positioned anywhere within a parent collection — including above articles — using the same drag‑and‑drop controls.This would allow better content organization and more intuitive navigation structures in the Help Center.
Please make the Monitors list view reflect the real review status. Right now, a conversation can be Submitted but still appear as Unreviewed in All reviews, which makes it hard to trust the list for what’s actually left to review.
Would really love to be able to create more dynamic workflows for Slack channel specific flows. Top priority would be to use Slack teammates as a condition in workflows so we aren’t hounded with noise from messages sent by internal employees in our externally connected channels.
The chart drill‑in view is very useful for exploring the records behind a metric. However, it currently can’t be saved or reused as its own chart in a report.It would be powerful if the drill‑in table could be saved as a reusable chart that can be added to custom reports. This would allow teams to:Turn drill‑in explorations into reusable report visualizations Preserve the same filters and analysis in reports Share the chart with teammates without rebuilding itThis would make drill‑in not just an exploration tool, but also a way to create reusable reporting charts.
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.