Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    3256 Ideas

    JHarlowe
    JHarloweConnector

    Allow for adding / generating unique Conversation or Ticket URLs in Workflow messagesSubmitted

    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.

    fieldworkNew Participant

    Requesting redirect URI allowlist for MCP DCR - FieldworkSubmitted

    Hi team,We're integrating Intercom's MCP server into Fieldwork, an AI agent platform for consumer-brand operators. Our users connect their own Intercom accounts, and the agent calls Intercom tools on their behalf.Dynamic Client Registration against https://mcp.intercom.com currently returns:{ "error": "invalid_redirect_uri", "error_description": "Redirect URI https://app.getfieldwork.ai/api/connectors/oauth/callback is not in the allowlist, reach out to Intercom Customer Support if you believe we should support it"}Following the format Seán set out in the earlier thread on this:Product or tool name: Fieldwork (https://getfieldwork.ai) Exact redirect URI to review: https://app.getfieldwork.ai/api/connectors/oauth/callback Production or staging: production (our only environment) MCP endpoint targeted: https://mcp.intercom.com Use case and distribution model: Fieldwork is a multi-tenant SaaS product. Each end user authorizes their own Intercom workspace through OAuth 2.1 authorization code with PKCE (S256); tokens are encrypted at rest (AES-256-GCM), scoped to the authorizing user, and never shared between users or organizations. The agent reads conversation and contact context, and takes actions in Intercom only when the user explicitly asks. Distribution is direct to our own customers — Intercom appears as one connector in our library, not resold or white-labeled.We don't have an Intercom workspace of our own to raise a support conversation from, which is why I'm posting here — I saw the community team was able to route a very similar request internally.Thanks,Guillaume DupuyFieldworkguillaume@getfieldwork.ai

    Terry Tafari1New Participant

    A workflow trigger when a conversation is assigned to a specific teammateSubmitted

     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.

    Belén De AngelisNew Participant

    Add an "Archived" status for Help Center articles, distinct from DraftSubmitted

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