Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    2702 Ideas

    Michael LeighNew Participant

    Sync Banner content to Fin AI knowledge baseSubmitted

    When a Banner is active in Intercom, teams should have the option to make its content available to Fin as a knowledge source. When the Banner is paused or deleted, that content should be automatically removed from Fin's knowledge base without any manual steps.The problemBanners are commonly used to communicate important product changes, outages, or announcements. In practice, many customers dismiss or skim banners without fully absorbing the information. This generates avoidable support volume — customers contact support asking questions the banner already answered.Fin has no visibility into active banner content today, so it cannot answer these questions accurately or consistently, even when the information is current and relevant.There are existing workarounds — such as creating a snippet or article with the same content — but these require manual cleanup after the banner is removed. Without that cleanup, outdated information remains in Fin's knowledge base, which creates a different problem.The proposed behaviourWhen creating or editing a Banner, an option is available to include the banner content in Fin's knowledge base. When that option is enabled and the banner is published, the content is automatically added as a contextual source for Fin. Fin can reference that content when responding to related customer questions while the banner is active. When the banner is paused or deleted, the content is automatically removed from Fin's knowledge base — no manual cleanup required.This closes a gap between what customers are told through banners and what Fin can actually answer. It reduces support volume during product change windows, improves the accuracy of Fin's responses, and removes a manual process that teams would otherwise need to manage themselves.

    CaoryNew Participant

    Make Messenger window movable or detachable for embedded editorsSubmitted

    We embed Intercom Messenger directly inside our product’s editor, and many users open a conversation specifically to ask questions while they continue editing. In this context, the current fixed-position Messenger window can cover important parts of the UI and make the editor hard to use.Our users are asking for the ability to freely move or detach the Messenger while keeping it open, so they can keep both the editor and the conversation visible and usable at the same time.Requested capabilities: Allow end users to move the Messenger window Make the Messenger window draggable by default, or Provide an option to enable “floating / draggable” mode per workspace or per app. Ideally remember the last position per user and restore it the next time they open the Messenger. Optional alternative: detachable / pop-out mode Provide a way to open the Messenger in a separate floating panel or browser window while keeping it connected to the current session. This would let users keep the editor full-screen while referencing the conversation side-by-side. Configuration for product teams A setting in Messenger configuration (e.g. “Allow users to move Messenger window”) so we can enable this behavior only on certain pages (such as editors, complex forms, or dashboards). An API hook/event so that we can react when users move or pop out the Messenger (for example, to adjust other UI elements). Why this matters: In tools with complex editors (site builders, app builders, design tools, etc.), users frequently need to ask questions while actively editing. A fixed Messenger that overlays the canvas or important controls leads to frustration. Allowing users to reposition or detach the Messenger would significantly improve usability and reduce friction, without requiring product teams to build their own support UI. This feature would help a lot of products where Intercom is embedded into a dense UI, and would directly address user feedback that “the chat gets in the way while I’m trying to work.”

    Roy
    Top Expert ✨
    RoyTop Expert ✨

    Dynamic UI Previews: Generating Ephemeral App Experiences from API Responses in Fin FlowsSubmitted

    ⚠️ Problem StatementCurrently, when a Procedure Builder configures a flow to fetch external data (e.g., retrieving a list of recent orders, linked accounts, or purchased products via an API), the experience often breaks continuity. After the data is fetched, Fin has to ask the user to manually type out the specific order number or product name into a blank text input. This manual transcription introduces friction, increases the margin for user error, and degrades the premium "app-like" messenger experience. ✅ Proposed Solution / Feature ConceptIntroduce an automated, temporary messenger app experience generated dynamically from API payloads. Instead of returning raw text or forcing a manual text reply, Fin should leverage an ephemeral UI component (a "Preview App") directly inside the messenger canvas.When an API response returns an array or an object collection, the Procedure Builder should be able to map those objects to interactive UI elements. The customer can then simply click/tap their selection from the visual response to advance the flow. 🛠️ Example Use Case / Flow Step 1: Fin initiates a backend check: "Display all orders for this customer." Current State: Fin lists the text or drops a blank input box: "Please type the order ID you are referring to." Proposed State: Fin renders an interactive list/carousel card component showing the last 3 orders (Order #, Date, Total). Step 2: The customer clicks the specific order card. Step 3: Fin instantly updates the context and moves to the next interactive picker: "Which product from this order are you referring to?" (Renders clickable Product Items).