Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    3479 Ideas

    Judy CorreiaNew Participant

    Recommendation Audit or CategorisationSubmitted

    Currently Fin Recommendations (content gaps, data gaps and action gaps) only have two options - reject or mark as done/approve. Rejecting removes the recommentation and stops Fin from suggesting it again in the future. In our case this is limiting as a recommendation (in particular or data and action gaps) may not be technically possible today, but as technology changes the recommendation may make sense at some future time. It would be amazing if recommendations had a option for a “soft rejection” where it may be rejected now but we’d like Fin to make the recommendation again (if warranted) at some future time, someting like “remind me again in X months”It would also be great if: there were an audit trail, where we could see what recommendations were accepted and rejected. In addition to an audit, being able to specify reason for rejection, this would help with identifying the recommendations that may not make sense today but could in the future. Currently to overcome this limitation in auditability and tracking we need to keep a running list of recommendations in a spreadsheet, noting the recommendation, when it was suggested and the reason for rejection and review it regularly to see what might be feasbile today that perhpas wasn’t a few months ago. This adds extra overhead to our process and means having to bounce between applications vs having one source of truth within Fin. 

    Jimmy HurffNew Participant

    Append Full Conversation History to Email Notications When Enabled / Add Deep Links to ConversationSubmitted

    This creates a frustrating user experience - the user gets an email that the conversation has been updated but they cannot see the entire thread within the email.  Here is a direct quote from an impacted customer:Good morning - This new chat system makes emails almost worthless because we often can’t tell which issue your answer is associated with. I would imagine you already know this but below is a good example if you do not.Proposed improvement #1: When a user is notified by email of an update to a conversation that they did not see in the messenger widget AND the company settings have conversation history enabled, send the entire history of the conversation.  See article below.https://www.intercom.com/help/en/articles/3527623-sending-email-notifications-without-conversation-content-or-historySpecifically, this callout:Important: If the email notification is sent because of user/lead inactivity from a conversation started from the Messenger, then it will only include the messages they haven't seen, not the full conversation history.I am not sure what the business rule / reason for this is.  If the config has been set to include the enable conversation history, all of the history should be sent. Proposed Improvement #2: An alternative option might be to include a deep link to the conversation.   If the user clicks the link, they are taken to a detailed view of the conversation directly.

    SlimNew Participant

    Simple arithmetic on attributes in Workflows and Reports (e.g. difference of two attributes in conditions and charts)Submitted

    Current behaviorAttributes (people, company, conversation, ticket, temporary) can only be used as-is. In workflows, a branch condition evaluates a single attribute against a value — there is no way to compute anything from two attributes (a difference, sum, or ratio) and branch on the result. The "Set attribute" step can only write a value, not a computed expression. In custom reports, charts aggregate existing attributes, but there are no calculated metrics or formula columns that combine two attributes.The problemA lot of very simple logic needs basic math on two attributes:Branch when the difference of two numeric attributes crosses a threshold — e.g. credit limit − amount spent, seats purchased − seats active, amount paid − amount refunded. The same for dates — e.g. the number of days between two date attributes. Report on a derived metric — e.g. the delta between two attributes and how it trends over time.Because no arithmetic is available, the only way to get this inside a workflow today is a Data connector step: send the two attributes to an external endpoint, do the subtraction there, write the result back into a third attribute, and only then branch on it. That means external infrastructure to build and maintain, an extra round-trip and failure point, and attribute clutter — all for one subtraction. In reporting, the same limitation means exporting data to spreadsheets or BI tools just to chart a simple derived value.Proposed ideaSupport simple arithmetic expressions (+, −, ×, ÷; ideally date differences too) wherever attributes are used:In workflow branch conditions — e.g. "If (Attribute A − Attribute B) is greater than X". In the "Set attribute" step — write a computed value into an attribute (temporary attributes would be a natural fit for intermediate results). In custom reports — a calculated metric / formula column combining existing attributes.Even a minimal version — attribute-minus-attribute in branch conditions plus one calculated-metric type in custom reports — would already remove the external Data connector round-trip for the most common case and immediately make reports richer.Who would benefitAny workspace whose people, company, conversation, or ticket data contains related numeric or date attributes — limits and usage, purchases and refunds, plan size and consumption, pairs of timestamps. Today these teams either maintain external compute endpoints for trivial math or export data to BI tools; native attribute arithmetic would make both unnecessary.

    SlimNew Participant

    Simple arithmetic on attributes in Workflows and Reports (e.g. difference of two attributes in conditions and charts)Submitted

    Current behaviorAttributes (people, company, conversation, ticket, temporary) can only be used as-is. In workflows, a branch condition evaluates a single attribute against a value — there is no way to compute anything from two attributes (a difference, sum, or ratio) and branch on the result. The "Set attribute" step can only write a value, not a computed expression. In custom reports, charts aggregate existing attributes, but there are no calculated metrics or formula columns that combine two attributes.The problemA lot of very simple logic needs basic math on two attributes:Branch when the difference of two numeric attributes crosses a threshold — e.g. credit limit − amount spent, seats purchased − seats active, amount paid − amount refunded. The same for dates — e.g. the number of days between two date attributes. Report on a derived metric — e.g. the delta between two attributes and how it trends over time.Because no arithmetic is available, the only way to get this inside a workflow today is a Data connector step: send the two attributes to an external endpoint, do the subtraction there, write the result back into a third attribute, and only then branch on it. That means external infrastructure to build and maintain, an extra round-trip and failure point, and attribute clutter — all for one subtraction. In reporting, the same limitation means exporting data to spreadsheets or BI tools just to chart a simple derived value.Proposed ideaSupport simple arithmetic expressions (+, −, ×, ÷; ideally date differences too) wherever attributes are used:In workflow branch conditions — e.g. "If (Attribute A − Attribute B) is greater than X". In the "Set attribute" step — write a computed value into an attribute (temporary attributes would be a natural fit for intermediate results). In custom reports — a calculated metric / formula column combining existing attributes.Even a minimal version — attribute-minus-attribute in branch conditions plus one calculated-metric type in custom reports — would already remove the external Data connector round-trip for the most common case and immediately make reports richer.Who would benefitAny workspace whose people, company, conversation, or ticket data contains related numeric or date attributes — limits and usage, purchases and refunds, plan size and consumption, pairs of timestamps. Today these teams either maintain external compute endpoints for trivial math or export data to BI tools; native attribute arithmetic would make both unnecessary.

    SlimNew Participant

    Reusable workflows: expose whether the workflow was triggered manually (trigger-source flag for branching)Submitted

    Current behaviorA reusable workflow can be started in two ways: by another workflow or automation via the "Pass to reusable workflow" step, or manually by a teammate from the Help Desk (⌘K → "Trigger reusable workflow"). Inside the workflow itself, there is no way to tell which of the two happened — branch conditions can only use people, company, and conversation data, and none of it reflects how the workflow was started.The problemThe same reusable workflow often needs to behave differently depending on how it was launched:When a teammate triggers it manually, automatic reassignment steps are unnecessary or actively harmful — they can pull the conversation away from the very teammate who just triggered it. For reporting and downstream logic, we want to set attributes differently per trigger source, so that manually triggered runs don't distort automation statistics (and vice versa). Some steps only make sense in one mode — e.g. an intro message or a snooze that fits the automated path but is redundant when a human is already handling the conversation.Because the trigger source is invisible, the only options today are:Duplicating the workflow into a "manual" and an "automated" version and keeping both in sync forever — which defeats the purpose of reusable workflows, or Having every parent workflow set a custom conversation attribute right before the "Pass to reusable workflow" step and branching on it inside the reusable workflow. This is fragile: every caller must remember to set it, the attribute has to be reset afterwards, and a manual trigger can't set anything beforehand at all.Proposed ideaExpose the trigger source inside reusable workflows — ideally as a boolean system attribute, e.g. "Workflow triggered manually" (true/false), available in branch conditions and when setting attributes.Example: if "Workflow triggered manually" = true → skip the reassignment branch and tag the run as manual; otherwise run the full automated path.A richer "Trigger source" attribute (manually / by another workflow) would be even more flexible, but even the minimal boolean would already let a single reusable workflow safely serve both cases instead of being duplicated.Who would benefitAny workspace that uses reusable workflows both as building blocks inside automations and as manual one-click actions for teammates in the Help Desk. Today those teams either maintain near-identical duplicated workflows or build fragile attribute-based workarounds; a native flag would remove the need for both.

    Matej Bosnjak
    Matej BosnjakConnector

    Feature Request: Folder / Collection Structure for Intercom Audiences (Segments)Submitted

    Hi everyone!  SummaryWe are building a structured segmentation system covering 8 countries × 6 license tiers × up to 7 roles per tier, plus driver, EMS, and product-specific sub-segments. This will result in 150–200+ audience segments in Intercom.At this scale, the flat list view of the Segments section becomes unmanageable. We are requesting a folder or collection structure for audience segments to enable organised navigation and team usability.Problem Intercom Segments currently exist in a single flat list with no grouping or hierarchy. With 150–200+ segments, finding the right audience requires scrolling or searching every time. There is no way to visually distinguish between segment types (e.g. country-based CPO segments vs. driver segments vs. product segments). This makes it difficult for support agents, Fin AI configuration owners, and CS managers to confidently navigate, audit, or update the correct segment. Onboarding new team members to the segmentation system becomes significantly harder without clear visual structure. Requested FeatureIntroduce folders or collections for the Segments section, allowing users to: Create named folders (e.g. 🇩🇪 Germany, 🇧🇪 Belgium, Business, Pro, Enterprise) Assign segments to folders — either at creation or via drag-and-drop / bulk assignment Expand / collapse folders in the sidebar or segment list view Nest segments logically without changing their underlying rules or behaviour Example StructureCopy📁 Germany (DEU) ├── DEU — Pro — Fleet Admin ├── DEU — Pro — Fleet Manager ├── DEU — Business — Finance Manager └── ...📁 Belgium (BEL) ├── BEL — Pro — Fleet Admin └── ...📁 Drivers ├── CC@home — Driver — Manual ├── CC@home — Driver — Automatic └── Reg. driver — no platform access📁 EMS ├── EMS — Dynamic (System Users) └── EMS — Static (Drivers)📁 Legacy (Wind-down) ├── All — Basic └── All — CompactImpact Area Current With Folders Segment navigation Scroll through 150+ flat entries Expand relevant folder, find segment instantly Fin AI configuration Error-prone — easy to select wrong segment Clear grouping reduces misconfiguration risk Team onboarding Requires tribal knowledge Self-explanatory structure Segment auditing Manual scan of full list Folder-level review Priority / Urgency We are actively building this segmentation system now and will reach 150+ segments within the next quarter. Without folder support, we may need to delay segment creation or work around the limitation with inconsistent naming conventions alone. This feature would benefit any Intercom customer operating at scale across multiple regions, products, or customer types. Workaround Currently UsedStrict naming conventions ({COUNTRY} — {Plan} — {Role}) allow alphabetical sorting to group segments loosely by country. However, this does not solve the navigation problem for cross-cutting segment types (drivers, EMS, product-specific) and is not intuitive for new team members.Additional Notes We would also welcome a search/filter bar within the Segments list as a lighter alternative or complement. A tagging system for segments (similar to Intercom tags on conversations) could achieve a similar result and may be simpler to implement.