Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    3383 Ideas

    Native export & import of Help Center / Knowledge articles (CSV, Markdown, HTML)Submitted

    The problemToday there is no way to export Help Center articles from the Intercom UI. The only option is the Articles API, which means writing a script or paying for a third-party migration tool. Importing is limited to specific integrations (Zendesk, Confluence, Guru, Notion). There is no file-based import.For teams without a developer at hand, this makes simple tasks unnecessarily hard:creating a backup of our knowledge base bulk-editing many articles at once (e.g. updating prices, product names, shipping info) translating articles outside of Intercom and bringing them back reviewing and improving content for Fin AI Agent in a structured wayThe ideaExport: A button in Knowledge to export all (or selected) articles, including collections, status, language versions and metadata, as CSV, Markdown or HTML (ZIP). Import: Upload the same format back to create new articles or update existing ones, matched by article ID. Ideally, include internal articles as well, not just public ones.Our use caseWe run a Shopify store and use Intercom with Fin for customer support. Our Help Center is the main knowledge source for Fin, so keeping it accurate and up to date is critical. Being able to export, edit in bulk and re-import would save us hours of manual copy & paste work every time our products or policies change.Why this helps othersThis request has come up in the community several times over the years. A native export/import would also cover backups and data portability, and make it much easier to keep Fin's knowledge base up to date.

    Arnaud VillenaveNew Participant

    Help Center pages fail Core Web Vitals (INP) since mid-August 2026 – impacting customers' SEOSubmitted

    Since around August 11, 2026, Google Search Console reports INP issues (longer than 200 ms, mobile) on our Intercom-hosted Help Center (help.libon.com).Before that date, we had no INP issues at all. Today, 261 URLs are affected, with a group INP of 223–227 ms, and the number keeps growing.Nothing changed on our side around that date: help.libon.com is a simple CNAME to eu.intercomhelpcenter.com, and we have no control over the Help Center's code, scripts or hosting. The sudden jump points to a change on Intercom's side (a Help Center release or infrastructure change around August 11). What we measured:Real-user data (PageSpeed / Chrome UX Report): Core Web Vitals fail on INP (213 ms). Real-user TTFB is 1.4 s. HAR capture (Slow 4G): 21 JavaScript chunks from static.intercomassets.eu (~400 KB) must download before the page finishes loading at ~4.5 s, delaying fonts until 3.4 s. The Messenger then adds ~285 KB. Lighthouse: Total Blocking Time 440 ms, render-blocking requests (est. 1.3 s savings), more than half of the Intercom JavaScript unused on page load.Since Google uses Core Web Vitals as a ranking signal, this directly affects the SEO of every customer using the Help Center, and customers have no way to fix it themselves.Request:Investigate what changed in the Help Center around August 11, 2026 and its impact on INP. Reduce and defer the JavaScript loaded on Help Center pages. Provide a native option to defer the Messenger on Help Center pages.Other customers: if you host your Help Center on Intercom, check Search Console → Core Web Vitals → Mobile. If you see the same jump in mid-August, please upvote and share your data here.

    Tony RomaNew Participant

    Make Block-type Dynamic Content visible to the Articles API - Beta feedbackSubmitted

    Block-type Dynamic Content is currently invisible to the Articles API; inline is partially visibleWe use the Articles API (get_article/update_article) to manage bulk content updates across our Help Center, and we ran a few tests to understand how Dynamic Content interacts with it.Inline Dynamic Content is represented in the body field returned by get_article as a placeholder token:#{{dynamic_content:content-name}}This at least tells us a reference exists and its name, even though the resolved value stays UI-only.Block-type Dynamic Content is completely absent from the API response regardless of whether the block holds text or an image. We confirmed this with three separate tests in the same article: a block-type text entry, an inline-type text entry, and an image inserted as a block. Only the inline entry appeared in the API body; the block-type text and the image were both invisible, even though all three render correctly in the editor and on the live page.This inconsistency matters for any team managing a Help Center via API-driven workflows: block-type usage is completely undetectable programmatically. A script auditing or updating article content has no way to know an article contains a block-type Dynamic Content reference.Requests, in order of usefulness to us:Represent block-type Dynamic Content in the API body the same way inline is handled with a placeholder token.Longer-term: expose a Dynamic Content read API so external tools can detect and enumerate usage across both types.