Share product ideas and upvotes with our product team
Summary: Requesting a way to automatically generate/add Spanish-language trigger phrases to Fin procedures, instead of manually creating a duplicate Spanish trigger for every English one.Use case: Reduces manual maintenance work on bilingual procedures and improves Fin's coverage for Spanish-speaking customers, which supports our CX goals.
Document parser breaks formatting on upload Summary: When uploading PDFs and DOCX files (e.g. into procedures/content for Fin), the document parser ruins formatting and messes up the document's organization, making the parsed content a mess.Details:Affected file types: PDF and DOCX Issue: parsing strips or scrambles formatting and structure, so the resulting content is disorganized and hard to use Impact: degrades quality of Fin's knowledge/procedures content, which hurts customer-facing answers and our CX scoreRequested fix: Preserve document formatting/structure during parsing. As an alternative or additional fix, native Markdown (.md) upload support would likely resolve this since it avoids the PDF/DOCX conversion step entirely.
The problem:Anyone managing high-volume tickets with a lot of automation will feel this one: the conversation feed is a single, unfiltered stream of everything; customer replies, agent responses, internal notes, macro outputs, workflow automation notes, system events; all mixed together in one wall of content.For us, this has gotten to the point where some teammates find it easier to jump to an external tool to review logs and automation history rather than scroll through the activity noise. What we'd love to see:A simple filter bar or option on the conversation / ticket feed that lets agents toggle which types of activity they want to see, with the ability to select multiple at once:✅ Customer messages ✅ Agent / support replies ✅ Internal notes (manually added by teammates) ✅ Automation notes (macros, workflow outputs, log links, etc.)Ideally the filter state would persist across the session so you don't have to re-apply it every time you open a ticket. Why it matters:It's a UI-level quality-of-life change, but the impact is real:Faster navigation in complex, note-heavy tickets Less context-switching to external tools A better experience for agents who work heavily with automationA great benefit for teams managing operationally complex conversations / tickets in Intercom.
Summary: We'd like the ability to grant teammates access to create and edit Fin Procedures without also giving them visibility into or access to Workflows, automation settings and other sensitive operational areas of our Intercom workspace. Current Behavior: Today, Procedures live within the Fin AI Agent tab, which is accessed via the "Can view Fin and Automation settings" permission. This same permission also exposes Workflows and Simple Automations. There is no way to grant procedure-building access in isolation, any teammate who can work on procedures can also see workflows. To prevent teammates from editing workflows, we can withhold the "Can manage Automation settings and inbound Workflows" and "Can manage outbound Workflows" permissions, but those teammates will still have full visibility into workflow configurations, which is not ideal from an access control and operational security standpoint. Requested Change: Introduce a dedicated permission (e.g., "Can manage Fin Procedures") that:Allows teammates to create, edit, and manage Fin Procedures Does not expose Workflows, Simple Automations, other automation settings or operationally sensitive areas of the workspace Can be granted independently of any workflow-related or data / security related permissionsUse Case: We want to involve subject matter experts and content contributors in building and refining Fin Procedures, teammates who understand our processes deeply but should not have access to the broader automation and workflow configuration of our workspace. Today, there's no clean way to enable this without overexposing sensitive operational settings. Desired Outcome:A permission model that lets us confidently delegate procedure authorship to a wider group of teammates, with clear boundaries that protect workflow integrity.
Would it be possible to make translated_content in the connector you have made for claude? Currently we have help center articles in multiple languages, but if we use Claude to assist in writing articles, we can only have them created in the same language which is set as default. This limitation makes it difficult incase we want to do mass edits. I understand from your Finbot, that it is possible to have it added as fx. danish or norwegian translation through the translated_content in the api. But also that this isn’t available as part of the MCP tool
Summary: The current email composer/reply pane within Intercom conversations is too small, creating workflow challenges—especially when drafting long responses or working with screenshots. Current LimitationAccording to FinAI’s assessment (Feb 2026), “The email composer in Intercom doesn't have a built-in option to resize or make the composition pane larger within a thread. The composer size is fixed in the interface.”This limitation becomes especially problematic when:Crafting long replies that require thorough review before sending Adding and reviewing multiple screenshots Editing complex messages that need more visual space Supporting detailed technical troubleshootingWorkaroundsIntercom teammates currently rely on non‑ideal workarounds such as:Drafting content in a full‑screen Help Center Article editor Drafting in a blank Outbound Email (full-screen editor) Copying/pasting the draft back into the conversation thread Requested EnhancementAdd the ability to:Resize the reply/composer pane within a conversation (drag to expand vertically and/or horizontally). Pop out the email composer into a separate, larger window—similar to pop‑out compose windows in Gmail, Outlook, and other messaging platforms.Expected BenefitsImproved agent productivity and response accuracy Faster handling of complex cases Better visibility when reviewing long replies Reduced cognitive load and fewer manual drafting workflows Better experience when working with screenshots, code snippets, or multi-step instructionsWhy This MattersClear, efficient communication is essential to customer support. A cramped composer can lead to errors, slower responses, and unnecessary friction. A resizable or pop‑out editor would meaningfully improve agent workflow and overall customer communication quality.
Presently, the team inbox capacity accounts for new conversations only. I would like to see the team inbox capacity account for new and reopened conversations, so that if the team inbox is set to have a capacity of 2 then I’d see the following: Agent has 2 conversations Customer replies to a conversation the agent previously responded I’d like to see this reopen conversation open in the team inbox rather than in the agent’s inbox if they are at capacity
As the Knowledge base manager, it would AMAZING if we could auto-sort help center collections by “Article Title A-Z/Z-A”, and "Created Date" Ascending/Descending, in addition only the custom sort option with all newly published article populating in a collection at the bottom of the list, that is currently functionality. It takes so much time to scroll down, drag, and scroll back to the top, EVERY time you publish a new article.
We might work a little differently than most companies, but our reps are typically assigned to one message type at a time. We will have a team on chats, a team on phone calls and a team on emails. It would be terrific if these conversations could easily be visually identified.I know we can do views, but it is still difficult to see what messages are chats vs emails vs phone calls when looking at a team inbox without setting up all of these views.
We have a lot of new customer support reps that are coming in and have given some incomplete or inaccurate answers. We would love the ability to tell Fin to use our stars for learning and answers, and ignore some who are training. Case in point, one of our new reps gave a wrong answer a few weeks ago (that was from Copilot while when we were just getting started and training both CoPilot and Fin) assuming it was correct. Fin still references this answer, even though it is wrong.We can avoid this by just having Fin only learn from our more experienced reps.
Just how phone calls have a different tune when they come in, I think it would be super helpful if live chat had a different ringtone as well! Or even being able to set a different ringer for differnet inboxes would be nice to recognize different inboxes that may have shorter first response times, closing times, etc.
Currently, Intercom does not provide a native export capability that allows teams to export all Knowledge content into a spreadsheet format such as Excel. Adding the ability to export published content, along with key metadata, would significantly improve content governance and operational efficiency.This functionality would support activities such as content audits, inventory management, reporting, and maintaining change logs outside of Intercom. Having a centralized export of all published Knowledge content would make it easier for teams to review content at scale, identify gaps or outdated information, and manage documentation processes across systems.Request: Feature request that enable administrators to export all Knowledge content and associated metadata to a downloadable Excel or CSV file. This export should all content types (i.e internal, public, snippets) and include both published and archived content. As well as relevant article details (e.g., title, status, author, last updated date, category, and URL).
Currently, callbacks are automatically assigned to a specific user rather than being left open for someone to pick up. This is disruptive to our workflow — we'd prefer to choose ourselves when we take a callback, similar to how tickets work today (where they sit available until someone claims them).Why this matters: Rejecting an assigned callback is time-consuming, and we're trying to work as efficiently as possible. Having callbacks behave like tickets — available for pickup rather than pre-assigned — would remove that friction.Suggested change: Make callback claiming behave like ticket claiming, i.e. queue-based/self-select rather than auto-assign.
Hello, I would like to request adding Azerbaijani language as supported language on help center, because we are having a lot of clients requesting support in AZ. Thank you!Eyeball Support
Currently, sending a bulk outbound email to a specific list of people requires: uploading a CSV via "Filter audience from CSV," having those contacts already exist in Intercom (the CSV only filters/tags existing users and leads — it doesn't create new ones), tagging them, then building an audience rule around that tag. If any of the target emails aren't already in Contacts, the CSV filter simply won't find or tag them, so they're silently excluded from the send. In practice this means before sending to a list, we first have to import those emails as contacts, then run the CSV filter to tag them, then build the message around the tag - and clean up duplicate contacts created in the process. For a simple "send this email to this list of people" task, that's a lot of manual setup and prone to errors (duplicates, silently dropped recipients). We'd like a simpler option: either paste a list of email addresses directly into the outbound message audience, or upload a CSV of emails, and have Intercom send to exactly those addresses - regardless of whether they already exist as contacts. This would remove the need to pre-populate Contacts just to do a one-off bulk send.
Our team treats chats and tickets differently once closed, but both the Email and Messenger settings currently apply one shared rule to both types, so we can't configure them to match our actual workflow.For chats, once closed we want them to stay closed - any reply, whether via Messenger or email, should route through our automation that converts it into a new ticket rather than reopening the original chat. This keeps chat volume clean and ensures the conversation gets proper ticket-level tracking, prioritization, and SLA handling instead of being buried as a reopened chat.For tickets, the opposite is true: once a ticket is closed, we generally want customers to be able to reply and reopen it directly, since the underlying issue may still need follow-up work by the same team, and creating a brand-new ticket would fragment the history and context of that case.Right now, because the setting doesn't distinguish between the two, we can't apply "prevent reopen, convert to new ticket" logic to chats without also affecting tickets in the same way (and vice versa). This forces us to either accept the wrong behavior for one type or manually catch and fix misrouted conversations - which is exactly the manual work we're trying to eliminate with our reopened-to-ticket automation. Splitting these into independent controls for chats and tickets (across both Messenger and Email) would let each conversation type follow the closure/reopen behavior that actually fits how our support and escalation process works.
Both the Email setting ("Create new conversations when customers reply to closed conversations," Settings > Channels > Email > Advanced) and the Messenger setting ("Prevent visitors replying to closed conversations," Settings > Channels > Messenger > General) only accept a minimum of 1 day. We need this configurable in minutes/hours (e.g. 30 min–1 hour) instead, so a reply shortly after closing doesn't reopen the original conversation. A 1-day window is too long for how quickly our conversations get closed and potentially replied to.
See this thread: https://community.intercom.com/topic/show?tid=32&fid=6
Current Behavior:The workflow action "Show expected reply time" produces incorrect German output in two ways: Pronoun formality ignored: Despite "Fin's pronoun formality" being set to "formal" (Sie), the German output uses the informal "Du" form — e.g. "Du erhältst Antworten hier und an user@mail" — instead of the correct formal "Sie erhalten Antworten hier und an user@mail." Grammatical error: The phrase "Wir antworten normalerweise in ein Tag" is grammatically incorrect. The correct German dative form requires "einem", not "ein": → "Wir antworten normalerweise in einem Tag." Current Output (example): "Das Team wird sich diesbezüglich melden. Wir antworten normalerweise in ein Tag. Du erhältst Antworten hier und an user@mail."Expected Output: "Das Team wird sich diesbezüglich melden. Wir antworten normalerweise in einem Tag. Sie erhalten Antworten hier und an user@mail."Steps to Reproduce:Set Fin's pronoun formality to "formal" in the Intercom settings. Create or use a workflow containing the "Show expected reply time" action. Trigger the workflow for a German-speaking user. Observe the reply message displayed.Impact:The informal "Du" address contradicts the configured communication standard and may appear unprofessional to customers. The grammatical error ("in ein Tag") reduces credibility and trust in automated responses.Proposed Fix:Ensure the "Show expected reply time" action respects the configured pronoun formality setting across all localized strings. Correct the German translation of the reply time string to use the grammatically correct dative form: "in einem Tag."
Allow bulk closing tickets/conversations with setting ticket attributes and ticket state.As well, allow bulk merging of conbvesrations/tivckets.
I would love to have some settings available that would make our workspaces look immediately different. This is gonna be crucial later on when we forget on which workspaces we are currently in. The easiest would be to change its colors or shades of colors, and later on even more.We might get into issues if we somehow reply as a different company in our tickets one day because of this.
CONTEXTJust had a 2 hour conversation with Fin AI that was confusing and it ended with me being told the metric I am using is a Legacy metric, which is why it is not matching with the Intercom-native reports I am seeing. Intercom currently has two Elasticsearch pipelines: a newer one used by current reporting charts and a legacy pipeline used by older charts. Because of this, some metrics in the reporting UI (for example “Conversation created at”) come from the legacy pipeline but are not clearly labeled as such. This makes it easy for users to select them without realizing they may not be the current source of truth. SUGGESTIONAdd a visible “Legacy” badge to these metrics. It would help customers quickly distinguish them from the newer reporting metrics and avoid confusion during the reporting transition.
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?
I am interested in allowing users to be able to test workflows within our test environment, but have been informed that permission sets must mirror the production environment. It would be incredibly helpful to allow more users to publish outbound messages/workflows within our test environment so that they don’t have to ask permission to test workflows within a controlled environment, where the impact to active users is removed.
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.