Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    3155 Ideas

    JHarlowe
    JHarloweConnector

    More Granular Permissions Set For ProceduresSubmitted

    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.

    Ami JasaniNew Participant

    Ability to Resize or Pop‑Out the Email Composer/Reply Pane in IntercomSubmitted

     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. 

    Diana ZeleninaNew Participant

    Separate closed-conversation reply settings for chats vs. ticketsSubmitted

    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.

    Peter SchöllNew Participant

    Bug Report: "Show Expected Reply Time" Action – Incorrect German LocalizationSubmitted

    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."